Codificador/Decodificador de URL
Codifica y decodifica URLs.
URL inválida
Tips
- El carácter japonés「あ」se codifica como
%E3%81%82en UTF-8. - Un espacio puede convertirse en
%20en rutas URL o en+en parámetros de consulta (diferencia entre RFC 3986 y la especificación de formularios HTML). - Los caracteres reservados como
?,&y=deben codificarse cuando se usan como valores de parámetros. - Útil para incluir caracteres no ASCII en parámetros de consulta de APIs REST o para pasar URLs de redirección de forma segura.
Preguntas frecuentes
%XX para que sean seguros en URLs. Decodificar revierte ese proceso al texto original legible.%20 en las rutas de URL (según RFC 3986). Usa + solo en cadenas de consulta application/x-www-form-urlencoded (datos de formularios HTML). Ante la duda, %20 es la opción más segura.- _ . ~ — pueden aparecer en URLs sin codificar. El resto, incluidos los caracteres reservados como & y =, deben codificarse cuando se usan como valores de parámetros.
A propósito — El nacimiento de la URL: Tim Berners-Lee y los albores de la World Wide Web
La URL fue diseñada en 1991 por Tim Berners-Lee, inventor de la World Wide Web. Originalmente estaba pensada solo para caracteres ASCII, por lo que los caracteres multibyte (como el japonés) y los caracteres especiales deben representarse mediante codificación porcentual.
La URL de la primera página web de internet, http://info.cern.ch/hypertext/WWW/TheProject.html, sigue siendo accesible hoy. Los dominios con emoji (p. ej., 🍕.ws) son técnicamente posibles y se convierten internamente a Punycode (formato que empieza por xn--). Aunque las URLs pueden superar teóricamente los 2,000 caracteres, los límites prácticos de navegadores y servidores rondan los 2,048 caracteres.
RFC 3986 define la especificación de URL, pero la distinción entre %20 (espacio) y + (espacio) sigue siendo una fuente habitual de confusión. %20 es el estándar URI; + se usa en el formato application/x-www-form-urlencoded de formularios HTML — la elección depende del contexto.