Codificador y decodificador de URL

La codificación porcentual en un párrafo

Una URL solo admite un conjunto pequeño de caracteres. Todo lo demás se escribe como un signo de porcentaje seguido de los dos dígitos hexadecimales de su byte: un espacio es %20, el signo # es %23. Los caracteres que no son ASCII se convierten primero a UTF-8 y recién después se escapan byte por byte, así que é se vuelve %C3%A9 — dos escapes para un solo carácter. Una herramienta que en su lugar produce %E9 está usando Latin-1 y va a fallar con cualquier cosa moderna.

Los caracteres que nunca necesitan escape

El RFC 3986 los llama no reservados: las letras A–Z y a–z, los dígitos 0–9 y los cuatro signos - . _ ~. Significan lo mismo escapados que sin escapar, así que escaparlos es legal pero inútil, y hace que dos URLs idénticas se vean distintas para una caché.

Después están los caracteres reservados —/ ? # [ ] @ : $ & ' ( ) * + , ; =— que son la puntuación que le da estructura a una URL. Que necesiten escape o no depende por completo de dónde estén. Dentro de un valor, un & suelto abre un parámetro nuevo y corta tus datos en silencio. En la URL misma, está haciendo su trabajo.

Cuál de los dos codificadores necesitas

Esta es la distinción que hace el selector de modo de arriba, y es la misma que hay detrás de las dos funciones de JavaScript:

• Un solo valor (encodeURIComponent) escapa también los caracteres estructurales. Úsalo para el valor de un parámetro, un segmento de ruta, un dato que escribió una persona. Aplícalo a una dirección entera y obtienes https%3A%2F%2Fexample.com, que es el comportamiento correcto y completamente inútil como enlace.
• URL completa (encodeURI) deja la estructura intacta y solo escapa lo que nunca puede aparecer en crudo, como los espacios y los caracteres acentuados. Úsalo para reparar una URL que alguien escribió con un espacio adentro. Nunca lo uses con un dato que vas a insertar, porque deja intacto un & y permite que el valor se salga de su parámetro.

El signo más es genuinamente ambiguo

En el formato application/x-www-form-urlencoded —lo que envían los formularios HTML y, por lo tanto, a lo que se parece la mayoría de las query strings— un espacio se escribe como +. En el RFC 3986, que rige las URLs en general, + es un signo más literal. Los dos son correctos en su propio contexto, y una query string no te dice cuál de las dos reglas la produjo.

La consecuencia práctica: un número de teléfono en una query string es una trampa. ?tel=+44123 llega a muchos servidores como " 44123". Si un valor puede contener un más, codifícalo como %2B y deja de confiar en cualquiera de las dos convenciones. La tabla de parámetros de arriba decodifica + como espacio, porque es el caso más común, lo que significa que muestra algo incorrecto cuando el más era literal.

La doble codificación, y por qué no se puede deshacer de forma confiable

Codifica una cadena dos veces y %20 se vuelve %2520, porque el propio signo de porcentaje queda escapado. La herramienta te avisa cuando ve ese patrón, y cuando una decodificación deja escapes atrás. Lo que no puede hacer es decirte si eso fue un error: una URL que contiene el texto literal 100%25 es algo perfectamente válido de guardar. Una vez que un dato doblemente codificado llega a una base de datos, la ambigüedad es permanente.

Lo que esta herramienta no resuelve

• Nombres de dominio internacionalizados. Un nombre de host como müller.de no se codifica con porcentajes: se convierte con punycode a xn--mller-kva.de, un algoritmo completamente distinto. Los escapes porcentuales dentro de un nombre de host no son válidos, y esta herramienta los va a producir sin protestar si se lo pides.
• Normalización. No pasa el esquema a minúsculas, no colapsa ../, no ordena parámetros ni resuelve una URL relativa contra una base.
• Validación. La salida está escapada correctamente; eso no significa que sea una dirección que funcione.
• Barras codificadas dentro de la ruta. %2F no es lo mismo que /, y muchos servidores y proxies lo rechazan o lo normalizan en silencio antes de que tu código llegue a verlo. Si un segmento de ruta tiene que contener una barra, pruébalo contra el stack real en vez de confiar en el escape.

Última actualización 19 de septiembre de 2026