URL Codificar / Decodificar
Convierte texto con codificación/decodificación URL en tiempo real. Útil para parámetros de consulta y URLs con caracteres no ASCII.
Otras herramientas
Artículos relacionados
📖 Dónde se suele tropezar
Codifica y descodifica texto para URLs mientras escribes, siguiendo encodeURIComponent, por completo en el navegador. No existe una única cosa llamada codificación de URL: qué caracteres hay que escapar depende de en qué parte de la URL vaya el valor. Un segmento de ruta, un valor de consulta y el envío de un formulario siguen reglas distintas, y confundirlas explica la mayoría de los fallos en este terreno.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Confundir encodeURI con encodeURIComponent | encodeURI existe para codificar una URL entera, así que deja a propósito los delimitadores en paz: /, ?, &, =, # y :. Úsalo sobre una URL que pasas como valor de consulta y los & y = de dentro de ese valor se leen como delimitadores y los parámetros se parten: ?redirect=https://a.com/?x=1&y=2 llega como dos parámetros, redirect e y. El síntoma es un valor cortado a medias, algo que probar con valores cortos jamás destapará. |
Usa siempre encodeURIComponent para las piezas de una URL: un valor de consulta, un segmento de ruta, el contenido de un fragmento son todos piezas. encodeURI sólo procede al pasar una vez una URL ya montada, algo que en la práctica surge rara vez. Más fiable todavía es no concatenar cadenas: usa URLSearchParams o new URL(). Escribe const u = new URL(base); u.searchParams.set("redirect", target); y la decisión sobre el escapado desaparece por completo. Considera cualquier punto donde se monte una URL por concatenación como un fallo esperando a ser descubierto. |
| Un signo más se convierte en un espacio | Hay dos formas de representar un espacio. La codificación en porcentajes de los URI usa %20, mientras que la codificación de formularios HTML, application/x-www-form-urlencoded, usa +. encodeURIComponent sigue la primera y produce %20, pero si el receptor lo interpreta como datos de formulario, un + auténtico dentro del valor se convierte en espacio. El daño es peor con los alias de correo: pasa user+tag@example.com por una cadena de consulta y se vuelve user tag@example.com, y nunca llega. El alfabeto estándar de Base64 también contiene +, así que los tokens en URLs sufren lo mismo. |
Usa URLSearchParams para construir cadenas de consulta. Escapa correctamente un + del valor como %2B y escribe los espacios como +, de modo que el resultado sigue siendo coherente aunque el receptor lo interprete como datos de formulario. Si tienes que montarla a mano, sustituye explícitamente + por %2B allí donde el valor pueda contener uno. Para Base64 en una URL, usa desde el principio el alfabeto apto para URL (- y _): más fiable que codificar en porcentajes el estándar. Como esto sólo se rompe cuando un valor casualmente lleva un +, asegúrate de que tus datos de prueba incluyan uno. |
| La doble codificación deja un rastro de %25 | Codifica por segunda vez una cadena ya codificada y el propio % se convierte en %25: %20 pasa a %2520 y el japonés %E3%81%82 a %25E3%2581%2582. Un receptor que descodifica una sola vez se queda con la capa sobrante, y en pantalla aparece el texto literal %20. La causa es que nadie decidió qué capa codifica, y la combinación clásica es un framework que codifica automáticamente mientras la aplicación codifica además a mano. Quitar cualquiera de los dos lo arregla, pero cuál quitar no se decide sin seguir el código. |
Decide un único lugar donde codificar y déjalo escrito: declarar que esta función recibe un valor ya codificado, o que sólo esta capa codifica, vuelve estructuralmente imposible la doble codificación. Y descodifica exactamente una vez: un bucle que diga aún quedan %, descodifica otra vez es una vulnerabilidad seria. Un atacante envía %252e%252e%252f; la primera descodificación da %2e%2e%2f y la segunda ../, con lo que se cuela por delante de tu comprobación de recorrido de rutas, que se ejecutó sobre el resultado de la primera. Evita el propio instinto de descodificar una vez más por si acaso. |
Los nombres de dominio usan Punycode, no codificación de URL. Un dominio internacionalizado se convierte a una forma como xn--r8jz45g.xn--zckzah antes de llegar al DNS: el navegador lo muestra en su escritura original en la barra de direcciones, pero eso es una cortesía visual; lo que se consulta de verdad es la cadena xn--. Como existe el phishing con caracteres visualmente parecidos —los ataques homógrafos—, los navegadores muestran la forma Punycode tal cual bajo ciertas condiciones, y desconfiar de un dominio conocido que de pronto aparece como xn-- es un hábito útil. Una cosa más: el fragmento de una URL, todo lo que sigue a la #, no se envía nunca al servidor: no aparece ni en los registros de acceso ni en los referentes, lo que lo hace más seguro que una cadena de consulta. Aun así queda en el historial del navegador, de modo que el principio de no meter secretos en las URL no cambia.
📖 Cómo usar
-
1
Ingresa el texto a codificarPega el texto y se codifica con encodeURIComponent en tiempo real.
-
2
Ingresa el texto codificadoPega la cadena codificada para decodificarla en tiempo real.
-
3
Copia el resultadoHaz clic en Copiar para usar el resultado.
❓ Preguntas frecuentes
¿Diferencia entre encodeURIComponent y encodeURI?
¿Qué pasa con los caracteres japoneses en URLs?
¿El símbolo + representa un espacio?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.