Codificador / Decodificador de URL gratuito

Lo que hace realmente la codificación de URL

La codificación de URL (también llamada codificación por porcentaje) es el mecanismo que la web utiliza para encajar datos arbitrarios de caracteres en una URL. Las URL se diseñaron originalmente para un alfabeto ASCII minúsculo -letras, dígitos y un pequeño conjunto de signos de puntuación-, y los caracteres ajenos a ese alfabeto (espacios, letras acentuadas, ampersands, barras que no separan rutas, emojis, todo lo cirílico, CJK o árabe) deben escaparse antes de poder viajar con seguridad por HTTP, registros del servidor, barras de direcciones, gestores de copiar y pegar y tuberías del shell. La regla de codificación es directa: tome la secuencia de bytes UTF-8 del carácter y escriba cada byte como un signo de porcentaje seguido de dos dígitos hexadecimales. Un espacio (un byte, 0x20) se convierte en %20. Un ampersand (0x26) se convierte en %26. El signo del euro € (tres bytes UTF-8 E2 82 AC) se convierte en %E2%82%AC. La forma codificada es reversible -cualquier analizador de URL de la web sabe decodificarla- y el resultado es una cadena que solo contiene caracteres ASCII «seguros».

Breve historia de la regla de codificación

La convención de codificación por porcentaje se remonta a RFC 1738 («Uniform Resource Locators (URL)», Tim Berners-Lee, Larry Masinter y Mark McCahill, diciembre de 1994), la primera especificación formal de URL publicada por el IETF. La RFC 1738 definió el conjunto original de caracteres «reservados» (caracteres con significado estructural en URL que deben codificarse cuando se usan como datos) y el conjunto original «no reservados» (caracteres que nunca necesitan codificación). La especificación se revisó sustancialmente en RFC 2396 (Berners-Lee, Fielding, Masinter, agosto de 1998) y nuevamente -de manera definitiva- en RFC 3986 «Uniform Resource Identifier (URI): Generic Syntax», Berners-Lee, Fielding, Masinter, enero de 2005), que sigue siendo hoy la especificación formal de URI. La RFC 3986 amplió el conjunto no reservado para incluir el carácter tilde (~), formalizó UTF-8 como codificación para los caracteres no ASCII en IRI y endureció las reglas sobre cuándo los caracteres reservados deben codificarse por porcentaje y cuándo deben dejarse tal cual. Para URI no ASCII, RFC 3987 («Internationalized Resource Identifiers», Duerst y Suignard, enero de 2005) definió la extensión IRI que permite que las URL contengan caracteres Unicode nativos, asignando la forma IRI a la forma URI estándar mediante UTF-8 + codificación por porcentaje. Para los nombres de dominio en concreto, RFC 3492 definió Punycode (Costello, marzo de 2003), la codificación utilizada para representar etiquetas de dominio Unicode (xn--exmpla-...) en DNS, estructuralmente similar pero con un algoritmo distinto. La especificación de URL de facto de la web moderna es el WHATWG URL Living Standard, editado por Anne van Kesteren, que codifica el comportamiento real de los navegadores -a veces divergiendo de la RFC 3986 por compatibilidad retroactiva con cómo funcionan las URL en la práctica.

Reservados, no reservados y los caracteres que siempre se codifican

La RFC 3986 divide los caracteres de URI en tres clases. Los caracteres no reservados -letras A-Z a-z, dígitos 0-9 y los cuatro signos - _ . ~- nunca necesitan codificación y nunca adquieren significado al codificarse. Los caracteres reservados -: / ? # [ ] @ ! $ & ' ( ) * + , ; =- tienen significado estructural en las URL (la barra separa segmentos de ruta, el signo de interrogación introduce la consulta, el ampersand separa parámetros de consulta, la almohadilla introduce el fragmento). Los caracteres reservados pueden aparecer sin codificar en su rol estructural; deben codificarse cuando se usan como datos ordinarios. Todos los demás caracteres -caracteres de control, espacios, el propio porcentaje y cualquier byte de una secuencia UTF-8 no ASCII- deben codificarse siempre por porcentaje. El carácter porcentaje es especial: debe codificarse como %25 cuando aparece como dato, porque un porcentaje sin codificar en un contexto de URL introduce una secuencia de escape porcentual que el analizador intentará decodificar. Saltarse ese paso produce algunos de los errores de manejo de URL más comunes.

encodeURI vs encodeURIComponent: cuándo usar cada uno

JavaScript trae dos codificadores integrados, ambos estandarizados en ECMAScript desde 1999 (ES3). La elección entre ellos es la decisión más común sobre codificación de URL en código web, y equivocarse produce errores sutiles que pasan las pruebas con entradas simples pero se rompen con datos reales de usuario que contienen ampersands, almohadillas o barras.

• encodeURIComponent: codifica todo salvo el conjunto no reservado. Úselo cuando codifique una sola pieza de datos que se incrustará en una URL: el valor de un parámetro de consulta, un segmento de ruta, un identificador de fragmento, el valor de un campo de formulario. La cadena hello world&more se convierte en hello%20world%26more: el ampersand interno queda codificado, así que no se interpreta como separador de parámetros cuando la URL se lea más tarde. Es la herramienta adecuada para «tengo entrada de usuario y quiero meterla en una URL con seguridad».
• encodeURI: codifica solo los caracteres que son ilegales en cualquier parte de una URL. Deja deliberadamente intactos los reservados (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) porque pueden estar haciendo trabajo estructural. Úselo cuando codifique una URL completa que ya tiene su estructura colocada: una URL con sus propios separadores ? y &, una URL con caracteres no ASCII en la ruta o la consulta que necesitan codificación sin alterar la gramática de la URL. La cadena https://example.com/search?q=hello world se convierte en https://example.com/search?q=hello%20world: las barras y el signo de interrogación se conservan, solo se codifica el espacio.

La regla mental: encodeURIComponent para datos, encodeURI para URL. Use el equivocado y romperá la estructura de la URL (encodeURIComponent sobre una URL entera escapa las barras y ampersands que necesitaba) o no escapará la entrada de usuario (encodeURI sobre un valor de consulta deja pasar los ampersands y sus datos serán interpretados como múltiples parámetros).

application/x-www-form-urlencoded: la otra codificación

Existe una segunda codificación, relacionada, usada específicamente para envíos de formularios HTML: application/x-www-form-urlencoded. Es casi idéntica a la codificación porcentual de URL salvo por un detalle: los espacios se codifican como + en lugar de %20. Esta convención proviene de la especificación original de formularios HTML y se conserva en el URL Living Standard específicamente para el serializador application/x-www-form-urlencoded. Los decodificadores de datos codificados como formulario deben revertir la convención: un + literal en datos de formulario se codifica como %2B, y un + en la cadena codificada se decodifica como espacio. La API URLSearchParams de JavaScript gestiona esta convención automáticamente; encodeURIComponent no: siempre codifica los espacios como %20. Para cadenas de consulta ensambladas a mano para una acción de formulario HTML, use URLSearchParams en lugar de llamar a encodeURIComponent sobre cada valor individualmente.

Cuándo necesita realmente esta herramienta

• Depurar una llamada a una API. Está consultando un endpoint REST con un parámetro de consulta que contiene espacios o caracteres especiales y recibe errores 400 o resultados inesperados. Codifique aquí el valor del parámetro, pegue el resultado en su petición y confirme que la API trata la entrada correctamente.
• Construir una URL compartible a mano. Componer un enlace profundo a una página de resultados de búsqueda, una vista filtrada de un panel SaaS o un formulario precargado: cualquier sitio donde necesite incrustar una consulta de búsqueda o un estado de selección dentro de la URL.
• Decodificar una URL capturada para leer lo que realmente contiene. Una URL registrada contiene %E2%9C%93%20done: ¿qué significa una vez decodificada? Pegue, pulse Decodificar y verá ✓ done.
• URL de OAuth y webhooks. El parámetro redirect_uri en flujos OAuth debe codificarse por porcentaje con precisión; equivocarse produce errores opacos de «redirect_uri mismatch». Las URL de webhook que contienen parámetros con datos de usuario requieren una codificación cuidadosa.
• Nombres de archivo con caracteres no ASCII en enlaces de descarga. Un enlace directo a un archivo llamado café-menu.pdf necesita que la é esté codificada por porcentaje para que el enlace funcione en todos los navegadores y herramientas del shell.
• Cadenas de conexión a bases de datos. Las URL de PostgreSQL, MySQL y bases de datos similares (postgres://user:p@ssw0rd@host/db) necesitan que la contraseña esté codificada por porcentaje si contiene @, :, / u otros caracteres reservados que confundirían al analizador de URL.

Seguridad: por qué la codificación importa más allá de la estética

La codificación incorrecta de URL es una fuente histórica de vulnerabilidades web. El HTTP response splitting explota saltos de línea no codificados (CR, LF, %0D%0A) en parámetros de URL que se reflejan en cabeceras HTTP, permitiendo a un atacante inyectar cabeceras arbitrarias o incluso una respuesta completa. Las redirecciones abiertas explotan un manejo ingenuo de URL que no decodifica ni valida correctamente las URL proporcionadas por el usuario antes de redirigir. La falsificación de peticiones del lado del servidor (SSRF) puede abusar de caracteres codificados para sortear listas blancas de URL: una expresión regular que bloquea «http://internal» pasa por alto «http://%69nternal» si el servidor decodifica después del filtro. La inyección SQL a través de parámetros de URL no es en sí un problema de codificación de URL, pero se agrava cuando las comillas simples y otros metacaracteres SQL sobreviven hasta la consulta de la base de datos. La recomendación de OWASP desde principios de los 2000 ha sido: codificar en la frontera al entrar, decodificar en la frontera al salir, no mezclar nunca formas codificadas y decodificadas en el mismo búfer. Esta herramienta ejecuta exactamente el paso de codificar/decodificar; lo que haga con el resultado depende de usted, y la responsabilidad de la seguridad está en la capa de aplicación.

Doble codificación: el error más común

La doble codificación ocurre cuando una cadena ya codificada se codifica de nuevo. El carácter espacio en una URL ya codificada es %20; codifíquelo otra vez y obtiene %2520 (porque % se codifica como %25). Cuando el receptor decodifica una vez, recupera %20 en lugar de un espacio. Cuando decodifica dos veces (en los raros casos en que la doble decodificación está soportada), obtiene el espacio, pero la mayoría de los analizadores no lo hacen, y la URL contiene silenciosamente un %20 visible en la barra de direcciones. La solución siempre es: decodifique primero si no sabe si la entrada ya está codificada, y luego codifique exactamente una vez. El mismo patrón aplica en código: nunca llame a encodeURIComponent dos veces sobre la misma cadena. Si tiene que pasar un valor de un contexto a otro, decodifique la codificación previa antes de volver a codificar para el nuevo contexto. El botón Intercambiar de esta herramienta ayuda con el ciclo de diagnóstico: pegue una URL sospechosa, pulse Decodificar para ver lo que hay dentro, pulse Intercambiar y pulse Codificar para recuperar la forma codificada canónica.

Privacidad: ejecución solo en el navegador

Las URL incrustan con frecuencia datos sensibles: tokens de autenticación en parámetros de consulta, identificadores de usuario en segmentos de ruta, consultas de búsqueda con contexto personal, valores de estado de OAuth, URL de webhook que incluyen claves de API. Los codificadores de URL del lado del servidor guardan una copia de cada URL que pega allí en sus registros. Esta herramienta usa las funciones integradas de JavaScript encodeURIComponent, encodeURI, decodeURIComponent y decodeURI ejecutándose localmente en su pestaña del navegador. Sin paso de subida, sin telemetría, sin registro: verifíquelo en la pestaña Red de DevTools mientras pulsa Codificar (no se dispara ninguna petición), o ponga la página fuera de línea (modo avión) tras cargarla y el codificador seguirá funcionando. Seguro para URL con tokens, claves de API, endpoints internos o cualquier URL que no quiera ver copiada en el disco duro de un desconocido.

Preguntas frecuentes

¿Cuándo debo codificar texto en URL?

Siempre que incruste entrada de usuario o datos con caracteres especiales en una URL: consultas de búsqueda en una cadena de consulta, nombres de archivo en una ruta, valores de parámetros en peticiones de API, destinos de redirección en flujos OAuth. Sin codificación, los caracteres especiales rompen la estructura de la URL (un & sin escapar dentro de un valor se interpreta como separador de parámetros) o introducen vulnerabilidades de seguridad (un salto de línea sin escapar habilita el HTTP response splitting). La regla práctica: cualquier cadena que contenga algo distinto de letras, dígitos y los cuatro signos -_.~ necesita codificación antes de entrar en una URL.

¿Qué es la doble codificación y cómo evitarla?

La doble codificación ocurre cuando un texto ya codificado se codifica una segunda vez, convirtiendo %20 en %2520 (porque el propio carácter porcentaje se codifica como %25). Los receptores que decodifican una sola vez recuperan la forma a medio decodificar en lugar del original. Siempre: si no sabe si una cadena ya está codificada, decodifíquela primero y codifíquela exactamente una vez. En código, nunca llame a encodeURIComponent sobre la salida de otro encodeURIComponent.

¿Es segura esta herramienta para URLs sensibles?

Sí. El codificador/decodificador usa funciones integradas de JavaScript ejecutándose enteramente en su navegador. La URL que pegue nunca cruza la red: verifíquelo en la pestaña Red de DevTools mientras pulsa Codificar (no se dispara ninguna petición), o ponga la página fuera de línea (modo avión) después de cargarla. Seguro para URL con tokens OAuth, claves de API, direcciones de endpoints internos o cualquier valor que no quiera ver registrado en un servidor de terceros.

¿Por qué mis datos de formulario tienen signos más en lugar de %20?

Los envíos de formularios HTML usan una codificación distinta pero relacionada llamada application/x-www-form-urlencoded, que codifica los espacios como + en lugar de %20 por convención histórica. Ambas formas son válidas en cadenas de consulta de URL; los analizadores modernos aceptan cualquiera. La API URLSearchParams de JavaScript usa la convención de formulario; encodeURIComponent siempre usa %20. Si sus datos deben interoperar con código antiguo de manejo de formularios, use URLSearchParams; en cualquier otro caso, sirve cualquiera de las dos.

¿Y los caracteres no ASCII y los emojis?

La codificación de URL moderna usa UTF-8: cada carácter no ASCII se convierte a su representación UTF-8 multibyte y luego cada byte se codifica por porcentaje. El signo del euro (€, tres bytes UTF-8) se convierte en %E2%82%AC; un emoji como el cohete 🚀 (cuatro bytes) se convierte en %F0%9F%9A%80. La RFC 3987 (IRI) y el WHATWG URL Standard formalizan ambos esta convención de UTF-8 primero. Sistemas más antiguos a veces usaban Latin-1 u otras codificaciones; si está decodificando URL antiguas y el resultado parece ilegible, la fuente puede haber usado otra codificación de caracteres antes de la codificación porcentual.

Herramientas relacionadas