Codificador / decodificador URL

Carácter	Código %XX	Ámbito predeterminado	Ejemplo codificado
espacio	%20	ninguno	a b → a%20b
« + »	%2B	ruta, URL completa	a+b → a%2Bb
« & »	%26	consulta, ruta, URL	a&b → a%26b
« = »	%3D	consulta, ruta, URL	a=b → a%3Db
« / »	%2F	ruta, URL completa	a/b → a%2Fb
« ? »	%3F	URL completa	a?b → a%3Fb
« # »	%23	URL completa	a#b → a%23b
« é »	%C3%A9	ninguno, 2 bytes UTF-8	été → %C3%A9t%C3%A9

¿Qué significan « encoder » y « decoder » en una URL?

Codificar una URL (« url encode », « urlencode ») transforma cada carácter prohibido en una dirección — espacio, acento, ampersand, signo más — en una secuencia formada por un porcentaje seguido de los dos dígitos hexadecimales de su byte. Decodificar una URL (« url decode », « decoder url ») lee estas secuencias al revés: los bytes se reconstruyen y luego se convierten en caracteres según la codificación declarada, normalmente UTF-8. Es exactamente esta pareja lo que la gente busca cuando escribe « encoder decoder url » o « percent encoding online ».

El percent-encoding no es ni compresión ni cifrado: una palabra acentuada se duplica de tamaño y cualquiera puede leerla a simple vista. Su único papel es hacer pasar cualquier byte por una URL, que por defecto solo admite un subconjunto de ASCII. Por el contrario, el Base64 sirve para transportar bytes por canales enteramente textuales: se parecen por fuera, pero no son intercambiables.

Cómo codificar una URL en percent-encoding

Paso 1: el texto se convierte en bytes según el juego de caracteres elegido, UTF-8 por defecto. Paso 2: para cada byte, se comprueba si el carácter correspondiente pertenece a la lista de caracteres permitidos para el ámbito seleccionado. Paso 3: si forma parte, se copia tal cual; si no, se convierte en %XX, con XX los dos dígitos hexadecimales del byte. Paso 4: si la opción espacio en + está activa, el byte 32 se reemplaza por un signo más en lugar de %20.

Ejemplo concreto: « café & été » en ámbito componente da caf%C3%A9%20%26%20%C3%A9t%C3%A9. Simplemente escribe este texto en el codificador: el resultado, el tamaño de entrada, el tamaño de salida y el coste adicional aparecen antes incluso de soltar la tecla.

Los cuatro ámbitos de codificación

El ámbito componente solo conserva las letras, los dígitos y - _ . ! ~ * ' ( ) : es el de un valor de parámetro, y corresponde a encodeURIComponent. La cadena de consulta conserva además los ampersand y los signos igual, para reconstruir una query string completa. El segmento de ruta permite / : @ & = + $ , ; para no romper las barras inclinadas. La URL completa añade todavía ?, #, [ y ] : casi nada se escapa, solo los espacios y los caracteres no ASCII pasan a %XX.

Cómo decodificar una URL codificada

El decodificador recorre la cadena de izquierda a derecha: un porcentaje seguido de dos dígitos hexadecimales da un byte, y cualquier otro carácter se copia tras convertirlo según la codificación elegida. Después los bytes se agrupan y se transforman en caracteres — dos para « é », tres para « 日 », cuatro para un emoji. La pestaña « Decodificar » muestra cada secuencia encontrada, su posición en la cadena, sus bytes y el texto correspondiente.

Si el porcentaje no va seguido de dos dígitos válidos, el error es explícito: secuencia incompleta o carácter hexadecimal no válido. El botón « Corregir los % » transforma los porcentajes aislados en %25, lo que hace la cadena decodificable sin perder información: la opción más segura para tratar una URL parcialmente escapada.

Espacio: %20 o + — la regla de los formularios

%20 es el espacio en percent-encoding estricto: funciona en la ruta, la consulta, el fragmento y las cabeceras. El signo +, solo es un espacio en el formato application/x-www-form-urlencoded usado por los formularios HTML y históricamente por las query strings. En el resto sigue siendo un signo más literal — y como es muy fácil de confundir, hay que escaparlo en %2B en cuanto se codifica un valor.

En la práctica: para rellenar un campo de formulario o reproducir el comportamiento de un <form>, marca « Espacio en + ». Para una URL de redirección, una canonical o un enlace compartido, prefiere siempre %20. El decodificador, en cambio, trata + como un espacio por defecto y puedes desactivar este comportamiento con un clic.

RFC 3986: unreserved, sub-delims y gen-delims

La RFC 3986 divide los caracteres ASCII en tres categorías. Los caracteres no reservados — letras, dígitos, - _ . ~ — se conservan siempre tal cual. Los subdelimitadores ! $ & ' ( ) * + , ; = y los delimitadores genéricos : / ? # [ ] @ tienen un significado estructural: separan la autoridad, la ruta, la consulta y el fragmento. Todo lo demás — espacio, comillas, signos angulares, llaves y porcentaje — debe codificarse.

Estas categorías son exactamente las que la pestaña « RFC 3986 & referencia » muestra carácter por carácter: haz clic en una ficha para ver su código hexadecimal, su categoría y los ámbitos que lo conservan. Es la referencia más rápida para responder a la pregunta « ¿tengo que escapar este carácter? ».

Caracteres acentuados, emojis y UTF-8

Una URL solo transporta bytes ASCII seguros, así que todo carácter superior a U+007F debe codificarse. En UTF-8, « é » vale C3 A9 y se convierte en %C3%A9, « 日 » vale tres bytes y produce tres secuencias, un emoji ocupa cuatro y se despliega en ocho caracteres codificados. Si el resultado te parece largo, no es un bug: es el precio de la compatibilidad con todos los protocolos. Por último, cuida el juego de caracteres de origen: decodificar en UTF-8 una cadena codificada en Latin-1 produce caracteres aberrantes, de ahí las cuatro opciones de la pestaña « Decodificar ».

Por qué encodeURIComponent no siempre basta

encodeURIComponent codifica todo salvo A-Z a-z 0-9 - _ . ! ~ * ' ( ), lo que sirve para un valor de parámetro pero rompe una URL completa, ya que también escapa las barras inclinadas, los dos puntos y los ampersand. encodeURI hace lo contrario: conserva la estructura de la URL pero deja pasar los espaces y los acentos, así que falla con un texto sin codificar. Los dos modos están cubiertos aquí — y mucho más, porque el ámbito « Cadena de consulta » y el ámbito « Segmento de ruta » llenan el hueco entre ambos.

Percent-encoding y Base64: dos herramientas distintas

El percent-encoding reemplaza byte a byte y conserva la legibilidad del texto original, a cambio de un alargamiento importante. El Base64 agrupa los bytes de tres en tres y los reescribe con un alfabeto de 64 caracteres: compacto pero totalmente ilegible, e inutilizable como tal en una URL sin la variante URL-safe. La pestaña « Codificaciones cruzadas » presenta las dos de un vistazo, con de regalo los bytes hexadecimales, las entidades HTML y la cadena JSON escapada: elige la representación adecuada antes de copiar nada.

Errores frecuentes: doble codificación y % aislado

El error más común es escapar dos veces la misma cadena: un espacio se convierte en %20, luego %2520, y el servidor recibe literalmente « %20 ». La segunda es olvidar el propio porcentaje, que debe convertirse en %25 — si no el decodificador lo toma como el inicio de una secuencia y falla o trunca. Por último, conservar un + sin escapar en un parámetro de formulario equivale a insertar un espacio que no pediste. El decodificador señala las secuencias mal formadas y el botón « Corregir los % » repara el segundo caso sin pérdida.

Dónde se esconden las URLs codificadas

En las query strings de seguimiento UTM, en las redirect_uri y los estados OAuth, en las webhooks cuya URL destino contiene parámetros anidados, en las URL de callback firmadas, en los registros del servidor, en los sitemaps y las canonical, en los <a href> generados en el cliente, en los JWT cuyo payload está en Base64URL, en los data: y las cabeceras Location, y en todo formulario HTML enviado en GET. Saber codificar y decodificar en un segundo evita abrir una terminal por una sola cadena.

Rendimiento y buenas prácticas

En el navegador, codificar y decodificar es lineal y no cuesta nada apreciable, ni siquiera con varios megabytes: cada carácter se procesa una sola vez, sin recursión ni asignaciones por carácter. Los únicos riesgos son la doble codificación — comprueba siempre el round-trip antes de guardar — y las URLs de varios kilobytes, que los proxies suelen truncar a partir de 2 000 caracteres. Documenta el ámbito usado junto a la cadena producida: « componente » y « URL completa » no dan el mismo resultado sobre el mismo texto.

Recomendado para

Desarrolladores back-end y front-end (query strings, redirecciones, OAuth), integradores y redactores técnicos (enlaces UTM, canonical, tracking), administradores y DevOps (webhooks, URLs firmadas, registros), testers y pentesters (fuzzing de parámetros, evasión de filtros), estudiantes (entender UTF-8, ASCII y RFC 3986) y cualquier persona que necesite un codificador y decodificador URL en línea rápido, completo y confidencial — con el complemento del codificador y decodificador Base64 y del formateador JSON.

Codificador y decodificador URL 100 % local: tus datos nunca salen de tu ordenador

A diferencia de los codificadores de URL en línea habituales, no se transmite ninguna cadena: la codificación, la decodificación, el análisis de URL y la reconstrucción de parámetros se ejecutan por completo en tu navegador. Así se puede escapar sin riesgo una URL de redirección interna, un token firmado, una cadena de conexión o un fragmento de código, incluso en modo avion o en una red pública. El historial y la última entrada se guardan localmente (localStorage) y permanecen en tu dispositivo.

La licencia Premium Volade añade una sincronización opcional en la nube, cifrada e independiente de la herramienta: el resto sigue siendo gratuito e ilimitado, sin registro.