BrowserTools
Inicio / Codificadores / Codificar / Decodificar URL

Codificar / Decodificar URL

Codifica o decodifica URLs y parámetros de consulta en porcentaje, modos seguro por componente y URI completa.

Cargando Codificar / Decodificar URL… Si no ocurre nada, activa JavaScript.

La codificación en porcentaje, comúnmente llamada codificación de URL, es el mecanismo definido en el RFC 3986 para representar de forma segura caracteres arbitrarios dentro de un Identificador Uniforme de Recursos. El sistema de direccionamiento de internet se diseñó en torno a ASCII, así que cualquier carácter fuera de un pequeño conjunto seguro (espacios, letras acentuadas, puntuación, emoji o binario en crudo) debe reemplazarse por un signo de porcentaje seguido de dos dígitos hexadecimales que representan el valor de byte del carácter en UTF-8. El esquema forma parte de la web desde que Tim Berners-Lee definió las URLs en el CERN en 1990 y se estandarizó formalmente en el RFC 1738, más tarde reemplazado por el RFC 3986 en 2005.

Ejemplos

Entrada hello world & co=1
Salida hello%20world%20%26%20co%3D1

Codificación en porcentaje (encodeURIComponent): el espacio se convierte en %20.

Entrada hello world & co=1
Salida hello+world+%26+co%3D1

Codificación de formulario (application/x-www-form-urlencoded): el espacio se convierte en +.

Preguntas frecuentes

¿Se suben mis datos a un servidor?
No. La codificación y la decodificación ocurren enteramente en tu navegador usando las funciones integradas de JavaScript encodeURIComponent, decodeURIComponent, encodeURI y decodeURI. Tu entrada nunca sale de tu dispositivo y no se hace ninguna petición de red.
¿Qué caracteres se consideran 'seguros' y se dejan sin codificar?
El RFC 3986 define los caracteres no reservados (A-Z, a-z, 0-9, guion (-), guion bajo (_), punto (.) y tilde (~)) como siempre seguros y nunca codificados. En el modo URI completa, los caracteres estructurales reservados (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) también se preservan porque tienen significado sintáctico en una URL completa.
¿Cuál es la diferencia entre los dos modos?
El modo por componente (encodeURIComponent) está diseñado para codificar valores individuales de parámetros de consulta o segmentos de ruta. Escapa todo excepto los caracteres no reservados, así que un ampersand dentro de un valor se convierte en %26 y no se confundirá con un separador de parámetros. El modo URI completa (encodeURI) está diseñado para URLs completas: preserva los caracteres estructurales reservados para que la URL siga siendo válida y analizable tras la codificación.
¿Por qué un espacio a veces se convierte en + y a veces en %20?
Depende del contexto. El formato application/x-www-form-urlencoded, usado por los formularios HTML, codifica los espacios como + por razones históricas. La codificación estricta en porcentaje definida por el RFC 3986 usa %20 para los espacios en todos los demás lugares, incluidos los segmentos de ruta y las cadenas de consulta modernas. En caso de duda, %20 es la opción segura; + solo debería decodificarse como espacio dentro del cuerpo de un formulario, no en una ruta de URL.
¿Hay caracteres que nunca puedan aparecer en una URL ni siquiera codificados?
Todos los bytes 0x00-0xFF pueden representarse en una URL mediante codificación en porcentaje, así que técnicamente cualquier secuencia de bytes es expresable. Sin embargo, existen límites prácticos: las URLs muy largas (más de 2000 caracteres) pueden ser rechazadas por navegadores, servidores o proxies. Los nombres de dominio internacionalizados (IDN) usan Punycode en lugar de codificación en porcentaje para la parte del host de una URL.
¿Esta herramienta gestiona correctamente Unicode y emoji?
Sí. La función encodeURIComponent de JavaScript convierte los caracteres a su secuencia de bytes UTF-8 antes de codificar en porcentaje cada byte, que es el comportamiento correcto según el RFC 3986. Por ejemplo, el signo del euro € (U+20AC) se convierte en %E2%82%AC, los tres bytes de su codificación UTF-8. Los emoji y cualquier otro punto de código Unicode se gestionan de la misma manera.
¿Puedo usar esto para decodificar una URL que se codificó dos veces?
Puedes aplicar la decodificación varias veces pegando la salida de nuevo como entrada. La doble codificación ocurre cuando una cadena ya codificada se vuelve a codificar, convirtiendo %20 en %2520 (el propio % se convierte en %25). Si ves secuencias literales %25 en una URL decodificada, el valor original estaba doblemente codificado y necesitas decodificarlo una segunda vez.
¿Es la codificación de URL lo mismo que la codificación de entidades HTML?
No. Son sistemas distintos. La codificación de URL usa la codificación en porcentaje (%20, %26, etc.) para hacer seguros los caracteres dentro de los URI. La codificación de entidades HTML usa referencias con nombre o numéricas (&,  , etc.) para escapar caracteres que tienen un significado especial en el marcado HTML. A veces se confunden porque ambas convierten & a %26 en una URL y a & en HTML, pero nunca deberían mezclarse.
¿Cuál es la diferencia entre un URI y una URL?
Un URI (Identificador Uniforme de Recursos) es el concepto más amplio: una cadena que identifica un recurso por nombre, ubicación o ambos. Una URL (Localizador Uniforme de Recursos) es un tipo específico de URI que proporciona el medio para localizar el recurso; incluye un esquema (https://), un host y una ruta. En el desarrollo web cotidiano los términos se usan indistintamente, pero técnicamente toda URL es un URI, mientras que no todo URI es una URL.
¿Por qué codificar una cadena ya codificada produce una salida ilegible?
Porque el signo de porcentaje (%) se codifica a su vez como %25, codificar una cadena ya codificada convierte cada secuencia %XX en %25XX. Por ejemplo, %20 se convierte en %2520. Decodifica siempre primero si no estás seguro de si la entrada ya está codificada, en lugar de codificarla otra vez. El modo de decodificación de esta herramienta restaurará la cadena original a partir de un único nivel de codificación.

Acerca de Codificar / Decodificar URL

La codificación de URL es ineludible siempre que construyes o analizas direcciones web mediante programación. Los valores de cadena de consulta que contienen espacios, ampersands o signos de igual romperían el análisis de parámetros si se dejaran sin codificar. Los envíos de formularios usan por defecto application/x-www-form-urlencoded, que codifica todo en porcentaje y convierte los espacios en +. Los clientes de API REST deben codificar los segmentos de ruta que contienen barras o signos de interrogación para que el servidor no los interprete como caracteres estructurales. Las cargas de webhooks, los URI de redirección de OAuth y los enlaces profundos dependen todos de una codificación y decodificación cuidadosas para pasar datos sin ambigüedad.

Esta herramienta gestiona la codificación y decodificación en porcentaje enteramente en tu navegador. Ofrece dos modos para coincidir con las dos funciones estándar de JavaScript. El modo por componente (equivalente a encodeURIComponent) está pensado para valores individuales (un término de búsqueda, un nombre de archivo, un parámetro de OAuth) y escapa todo excepto los caracteres no reservados A-Z, a-z, 0-9, guion, guion bajo, punto y tilde. El modo URI completa (equivalente a encodeURI) preserva los caracteres estructurales de una URL completa (dos puntos, barra, signo de interrogación, almohadilla, ampersand, igual) y es útil cuando quieres normalizar una URL sin romper su estructura. Como todo se ejecuta localmente, ninguna entrada se envía nunca a un servidor.

Un error común es codificar una URL entera con encodeURIComponent: esto escapa los dos puntos y las barras, produciendo una dirección rota. Usa el modo por componente solo en valores individuales antes de ensamblarlos en una URL. A la inversa, olvidar codificar valores que contienen & o = dentro de las cadenas de consulta hace que los parámetros se dividan o fusionen en silencio en el extremo receptor. Ten en cuenta también que el carácter + significa un espacio solo dentro de los cuerpos application/x-www-form-urlencoded; en los segmentos de ruta, un + literal debe codificarse en porcentaje como %2B.

Cómo la codificación en porcentaje obtuvo su nombre

La codificación en porcentaje toma su nombre del literal signo de porcentaje (%) que usa como carácter de escape. Cuando Tim Berners-Lee definió la sintaxis de URL en el CERN en 1990, necesitaba una forma de representar bytes arbitrarios que fuera inequívoca en texto ASCII. Eligió % porque era imprimible, rara vez se usaba en los identificadores y era visualmente distinto, lo que hacía fáciles de detectar de un vistazo las secuencias codificadas.

La especificación original de URL (RFC 1738, 1994) ya exigía la codificación en porcentaje para los caracteres inseguros, pero distintos sistemas discrepaban sobre qué caracteres eran 'inseguros' y cómo manejar Unicode. Hubo que esperar hasta 2005, y al RFC 3986, para que surgiera un estándar definitivo, junto con un documento complementario (RFC 3987) que definía los IRI (Identificadores de Recursos Internacionalizados), que permiten caracteres Unicode directamente en la sintaxis.

Hoy, prácticamente todos los lenguajes de programación incluyen una función de codificación de URL en su biblioteca estándar, pero persisten diferencias sutiles: el urlencode() de PHP codifica los espacios como +, el urllib.parse.quote() de Python usa %20 y el encodeURIComponent() de JavaScript sigue el RFC 3986. Esta diversidad es la razón por la que las integraciones de API entre lenguajes a veces tienen problemas con desajustes de codificación: el mismo carácter puede verse completamente distinto según qué biblioteca lo serializó.

Apoyar