Codificador y decodificador de URL

Qué hace esta herramienta

Las URLs solo pueden contener un conjunto limitado de caracteres ASCII. Cualquier otra cosa — espacios, caracteres chinos, &, =, ?, # y la mayoría de la puntuación — tiene que codificarse por porcentaje como bytes %XX antes de poder viajar de forma segura en un enlace, el envío de un formulario o una llamada a una API. Esta página hace esa codificación en ambos sentidos y, a diferencia de la mayoría de los codificadores, también descompone el resultado: pega cualquier URL o cadena de consulta y los parámetros aparecen como una tabla decodificada de clave-valor, para que puedas leer un enlace de seguimiento o una redirección OAuth de un vistazo.

El texto se trata como UTF-8, así que 中文 se convierte en %E4%B8%AD%E6%96%87 exactamente como esperan los navegadores y los servidores. La decodificación es tolerante: un % suelto que no sea un escape válido se deja tal cual en lugar de lanzar un error, y + se trata como un espacio cuando estás decodificando datos de formulario.

Codificación de componente frente a URL completa

Codificar componente es el encodeURIComponent de JavaScript: escapa todo excepto letras, dígitos y -_.!~*'(). Úsalo para un solo valor que va en un parámetro de consulta, un segmento de ruta o un campo de formulario. Codificar URL es encodeURI: deja intactos los caracteres estructurales :/?#[]@!$&'()*+,;= para que una dirección completa siga siendo una dirección válida, y solo escapa los espacios y el texto no ASCII. Usar el equivocado es el error clásico: encodeURIComponent sobre una URL completa convierte cada / en %2F y rompe el enlace, mientras que encodeURI sobre un valor que contiene & lo divide silenciosamente en dos parámetros.

La opción Espacio como + alterna entre %20 (RFC 3986, usado en las URLs) y + (application/x-www-form-urlencoded, usado en los cuerpos de formularios HTML y en muchas cadenas de consulta antiguas). Ambos se decodifican correctamente aquí; elige la codificación que espere tu destino.

Errores comunes

Doble codificación: codificar un valor ya codificado convierte %20 en %2520 y el servidor ve un %20 literal. Si tu salida decodificada todavía contiene secuencias %XX, decodifícala una vez más. Olvidar codificar & o # dentro de un valor trunca el parámetro. Codificar la URL completa con encodeURIComponent rompe el esquema y las barras. Mezclar las convenciones de + y %20 entre el cliente y el servidor produce signos de más en los nombres de usuario. Por último, la codificación por porcentaje no es cifrado ni ofuscación: un valor es totalmente legible después de decodificarlo, así que nunca confíes en ella para ocultar tokens; si necesitas opacidad para una carga útil, Base64 es la codificación de transporte habitual, y también es trivialmente reversible.

Contexto: de dónde viene la codificación por porcentaje

La codificación por porcentaje se definió con la primera especificación de URL, RFC 1738 (1994), escrita por Tim Berners-Lee y colegas, y se refinó en RFC 3986 (2005), que es el estándar actual para la sintaxis de los URI. El mecanismo de escape con % es anterior al dominio de UTF-8, y por eso los sistemas más antiguos a veces codifican bytes en Latin-1 o Shift-JIS y producen mojibake al decodificarse como UTF-8; el estándar de URL de HTML5 (WHATWG) finalmente obligó a usar UTF-8 para las nuevas codificaciones. La convención de + para el espacio proviene de la especificación aparte de formularios HTML, no del estándar de URL, que es la razón histórica por la que hoy coexisten dos codificaciones del espacio.

Dónde se usa

Construir peticiones a APIs a mano (términos de búsqueda, filtros, URLs de retorno), depurar enlaces de seguimiento de plataformas publicitarias (utm_source, gclid, fbclid), leer redirecciones OAuth y SSO (redirect_uri, state, scope), construir enlaces mailto: y tel: con asuntos y cuerpos, compartir enlaces que contienen rutas en chino o japonés, e inspeccionar cargas útiles de webhooks enviadas como datos de formulario. La tabla de parámetros es cómoda para pegar una URL larga de un ticket de soporte y ver exactamente qué se solicitó. Los valores dentro de una cadena de consulta suelen ser JSON o Base64: decodifica aquí primero y luego pega el valor en la herramienta correspondiente.

Preguntas frecuentes