URL Encode y Decode

Codifica y decodifica URLs con caracteres especiales. UTF-8 completo.

encodeURIComponent() — codifica todo excepto A-Z a-z 0-9 - _ . ~

¿Te ha servido esta herramienta?

¿Desarrollas aplicaciones web?

Herramientas de productividad para devs

Ver OCC →

¿Qué es URL encoding (percent-encoding)?

URL encoding, formalmente conocido como percent-encoding, es el mecanismo estandarizado en el RFC 3986 para representar caracteres especiales en URLs (Uniform Resource Locators) utilizando el formato %XX, donde XX es el código hexadecimal del byte del caracter en codificación UTF-8. Este mecanismo existe porque la especificación de URLs solo permite un subconjunto limitado de caracteres ASCII llamados "caracteres no reservados": las letras A-Z y a-z, los digitos 0-9, y cuatro caracteres especiales: guion (-), punto (.), guion bajo (_) y virgulilla (~). Cualquier otro caracter debe codificarse para ser incluido de forma segura en una URL.

Los caracteres reservados en URLs tienen significados especiales en la sintaxis: la barra (/) separa segmentos del path, el signo de interrogación (?) introduce los query parameters, el ampersand (&) separa parámetros, el numeral (#) indica el fragmento, el signo igual (=) asigna valores a parámetros, y los dos puntos (:) separan el esquema del host y el host del puerto. Cuando necesitas incluir alguno de estos caracteres como dato (no como parte de la estructura de la URL), debes codificarlo. Por ejemplo, si un parámetro de busqueda contiene el caracter &, debe codificarse como %26 para que no se interprete como separador de parámetros.

encodeURI vs encodeURIComponent: cuando usar cada uno

JavaScript proporciona dos funciones nativas para codificación de URLs que tienen propositos diferentes y es fundamental saber cuando usar cada una. La función encodeURI() codifica una URL completa, respetando los caracteres estructurales que forman parte de la sintaxis de URLs (como :, /, ?, #, &, =). Esto la hace adecuada para codificar una URL entera que contiene caracteres no-ASCII en el path o en los nombres de parámetros, pero que necesita mantener su estructura intacta.

La función encodeURIComponent() codifica todo el texto excepto los caracteres no reservados (A-Z, a-z, 0-9, -, _, ., ~). Esto incluye los caracteres estructurales de URLs, lo que la hace ideal para codificar valores individuales de query parameters. Por ejemplo, si quieres pasar la URL "https://ejemplo.com" como valor de un parámetro redirect_url, debes usar encodeURIComponent para que las barras y los dos puntos se codifiquen: "https%3A%2F%2Fejemplo.com".

Un error común entre desarrolladores es usar encodeURI cuando deberían usar encodeURIComponent, o viceversa. Si codificas el valor de un parámetro con encodeURI, caracteres como & o = no se codificaran y rompran la estructura de la query string. Si codificas una URL completa con encodeURIComponent, los caracteres estructurales como :// y / se codificaran y la URL dejará de ser válida. Nuestra herramienta ofrece ambos modos para que puedas seleccionar el apropiado según tu caso de uso específico.

Caracteres que necesitan codificación URL y por que

Los caracteres más frecuentemente codificados en URLs son los espacios, que se representan como %20 (o como + en el formato application/x-www-form-urlencoded usado por formularios HTML). Los caracteres acentuados del español requieren múltiples secuencias de escape porque en UTF-8 ocupan más de un byte: la a con tilde (a) se codifica como %C3%A1 (dos bytes), la ene se codifica como %C3%B1, y la u con diéresis como %C3%BC. Los emojis, al ocupar hasta 4 bytes en UTF-8, generan secuencias aún más largas.

Los caracteres reservados que necesitan codificación cuando se usan como datos incluyen: & (ampersand, %26), = (igual, %3D), + (más, %2B), / (barra, %2F), ? (interrogación, %3F), # (numeral, %23), % (porcentaje, %25), y @ (arroba, %40). Es especialmente importante codificar el caracter % cuando aparece como dato, ya que el navegador podría interpretarlo como el inicio de una secuencia de escape existente, causando errores de decodificación difíciles de depurar.

URL encoding en la práctica: casos de uso reales

Parámetros UTM para marketing: Los enlaces UTM se usan para trackear campanas de marketing en Google Analytics. Los parámetros utm_source, utm_medium y utm_campaign frecuentemente contienen texto con espacios, tildes o caracteres especiales. Por ejemplo, utm_campaign=promoción-verano-España necesita codificarse correctamente para que Analytics interprete el parámetro completo. Un error de codificación puede hacer que los datos de la campana se fragmenten en múltiples entradas en tus informes.

APIs REST y webhooks: Al construir URLs para peticiones GET a APIs, los valores de los parámetros deben codificarse con encodeURIComponent. Si pasas una dirección de email como parámetro (?email=usuario@ejemplo.com), el caracter @ debe codificarse como %40. Si el valor contiene ampersands o signos de igual, es critico codificarlos para que no se interpreten como delimitadores de la query string.

Redireccionamientos: Los sistemas de redirección frecuentemente necesitan pasar la URL de destino como parámetro de otra URL. La URL de destino completa (con sus propios parámetros) debe codificarse con encodeURIComponent para evitar conflictos entre los parámetros de la URL de redirección y los de la URL de destino. Este es uno de los escenarios más propensos a errores si no se codifica correctamente.

SEO y URLs amigables: Las URLs de páginas con contenido en español frecuentemente contienen caracteres que necesitan codificación. Un título como "Guia de nutrición para niños" genera una URL que contiene tilde en "nutrición" y ene en "niños". Aunque los navegadores modernos muestran estos caracteres de forma legible en la barra de direcciones, internamente la URL usa codificación percent-encoding. Es importante que tu CMS o framework genere estas URLs codificadas correctamente para evitar errores 404.

Decodificación de logs y analytics: Los logs de servidores web y los informes de herramientas de analytics frecuentemente muestran URLs con secuencias %XX. Decodificarlas es necesario para entender que busco el usuario, que parámetros envío, y que páginas visito. Nuestra herramienta permite pegar estas URLs codificadas y obtener el texto legible al instante.

Errores comunes en URL encoding y como evitarlos

El error más frecuente es la doble codificación (double encoding). Ocurre cuando una URL que ya está codificada se codifica nuevamente, convirtiendo %20 en %2520, %26 en %2526, etc. Esto produce URLs inválidas que el servidor no puede interpretar correctamente. Para evitarlo, siempre verifica si tu texto ya contiene secuencias percent-encoded antes de codificarlo.

Otro error común es usar encodeURI cuando se necesita encodeURIComponent (o viceversa). Como regla general: usa encodeURIComponent para codificar valores de parámetros individuales, y encodeURI solo cuando necesitas codificar una URL completa que contenga caracteres no-ASCII pero cuya estructura debe mantenerse intacta.

Un tercer error es olvidar codificar el caracter + (más). En el formato application/x-www-form-urlencoded (usado por formularios HTML), el + representa un espacio. Pero en percent-encoding estándar, + es un caracter literal que no se interpreta como espacio. Si tu valor contiene un + literal y usas el formato de formularios, el receptor lo interpretara como un espacio. Codifica + como %2B cuando necesites que se mantenga como el caracter más.

Preguntas frecuentes

¿Cuál es la diferencia entre %20 y + para representar espacios? Ambos representan un espacio, pero en contextos diferentes. %20 es la codificación percent-encoding estándar (RFC 3986) usada en URLs generales. El + se usa solo en el formato application/x-www-form-urlencoded que emplean los formularios HTML al enviar datos por GET. En la práctica, la mayoría de servidores web aceptan ambos, pero es mejor usar %20 en URLs y + solo en datos de formularios.

¿Por que la ene se codifica como %C3%B1 y no como un solo código? La codificación URL trabaja a nivel de bytes, no de caracteres. En UTF-8, la ene ocupa 2 bytes (0xC3 y 0xB1), por lo que se codifica como dos secuencias percent-encoded. Los caracteres ASCII (como A-Z y 0-9) ocupan 1 byte y generan una sola secuencia. Los emojis pueden ocupar hasta 4 bytes y generar cuatro secuencias.

¿Mis datos se envian a algún servidor? No. Todo el procesamiento de codificación y decodificación se realiza localmente en tu navegador mediante las funciones nativas de JavaScript (encodeURI, encodeURIComponent, decodeURI, decodeURIComponent). Ningún dato se transmite a servidores externos.

¿Puedo usar esta herramienta para codificar URLs con emojis? Sí. Los emojis son caracteres Unicode válidos que se codifican correctamente en UTF-8. Por ejemplo, el emoji de corazón se codifica como una secuencia de cuatro bytes percent-encoded. La herramienta maneja correctamente todos los caracteres Unicode, incluyendo emojis, ideogramas CJK, y caracteres de escrituras no latinas.

¿Qué pasa si intento decodificar una cadena que no está codificada? Si la cadena no contiene secuencias percent-encoded (%XX), se devolverá sin cambios. Si contiene secuencias percent-encoded inválidas (como %ZZ, que no es hexadecimal válido), la herramienta mostrará un error indicando que la cadena contiene secuencias de escape inválidas.

Revisado por Javier Andreo

Fundador de OCC · Actualizado: Mayo 2026