Codificador / Decodificador de URL y parser de query strings

encodeURIComponent() escapa casi todo, así que es lo que usas sobre una sola pieza de una URL: un valor de query, un segmento de ruta. encodeURI() deja intactos los caracteres reservados : / ? # & = + e incluso #, así que es lo que usas sobre una URL ya montada a la que solo hay que limpiarle los espacios y los caracteres no ASCII. Pasa una URL completa a encodeURIComponent y se convierte en un bloque opaco (https%3A%2F%2F…); pasa un solo valor a encodeURI y cualquier & que contenga se vuelve, en silencio, un separador de parámetros. El modo Encode de aquí expone ambos: el predeterminado es la regla de componente, y la casilla «Whole URL» es encodeURI() byte a byte.

Los dos son correctos, en sitios distintos. RFC 3986 solo conoce %20. La convención del + viene del envío de formularios HTML (application/x-www-form-urlencoded) y se aplica a los cuerpos de formulario y, por vieja costumbre, a los query strings — por eso URLSearchParams decodifica + como espacio pero lo deja intacto dentro de una ruta. Es decir: %20 siempre es seguro, mientras que + solo es un espacio si quien generó el valor lo decidió así. El modo Decode te muestra qué convención aplicó y te deja invertirla, para que puedas distinguir «Ada+Lovelace» el nombre de «Ada Lovelace» las dos palabras.

La codificación porcentual reemplaza un byte por un % seguido de ese byte escrito como dos dígitos hexadecimales. Una URL solo puede transportar un conjunto pequeño de caracteres ASCII, así que todo lo demás —un espacio, un acento, un emoji o un carácter reservado usado como dato— se convierte primero en bytes UTF-8 y luego cada byte se escribe como %XX. é son dos bytes, así que se vuelve %C3%A9. Decodificar hace lo inverso: reunir los bytes y volver a leerlos como UTF-8.

Decodifícala dos veces. %2520 significa que el % de %20 fue codificado a su vez como %25, lo que pasa cuando un cliente llama a encodeURIComponent() sobre un valor que ya estaba codificado: el clásico fallo del redirect_uri de OAuth. Esta herramienta lo detecta: pega el valor en el modo Decode y te avisará de que la primera pasada aún contiene escapes, te mostrará lo que produce una segunda pasada y te ofrecerá un botón «Decode again». El arreglo real está aguas arriba: codificar exactamente una vez, en el momento de meter el valor en la URL.

Porque los bytes escapados no son UTF-8 válido. %C3%A9 es una secuencia de dos bytes bien formada y decodifica a é, pero %E9 por sí solo es el byte Latin-1 (ISO-8859-1) de é y no es UTF-8 legal, así que decodifica a U+FFFD, el carácter de reemplazo. Esta herramienta nombra los bytes problemáticos en lugar de lanzar el URIError que lanzaría decodeURIComponent(), lo que te dice que el valor se codificó desde la codificación de origen equivocada en vez de dejarte adivinando.

Nada en el estándar de URL dice cuál gana, así que aquí se lista cada fila y las posteriores se marcan como duplicadas. En la práctica PHP y Express se quedan con el último valor, r.URL.Query() de Go devuelve todos, ASP.NET los une con comas y Rails solo los agrupa cuando la clave termina en []. Ese desacuerdo es justamente la razón por la que una herramienta debe mostrarte todos los valores en vez de elegir uno en silencio.

Punycode es la codificación ASCII de un nombre de dominio internacionalizado. DNS solo transporta etiquetas ASCII, así que münchen.example se convierte en xn--mnchen-3ya.example antes de cualquier resolución — y esa forma ASCII es también la que tiene que coincidir con un certificado TLS. El parser de aquí muestra el host convertido con el nombre que escribiste justo debajo, para que puedas detectar un dominio parecido. Deliberadamente no convierte punycode de vuelta a Unicode: mostrar como bonito Unicode un nombre suministrado por un atacante es exactamente cómo funciona el phishing homográfico.

El conjunto no reservado de RFC 3986 §2.3: A–Z, a–z, 0–9 y las cuatro marcas - . _ ~. Son seguros en cualquier posición y no deben codificarse gratuitamente, porque %2D y - son la misma URL y recodificarlos rompe los esquemas de firma que hashean la cadena en bruto. Ojo: encodeURIComponent() también deja intactos ! ' ( ) *, una herencia del antiguo conjunto «mark» de RFC 2396. RFC 3986 lista esos cinco como subdelimitadores, así que el modo de componente de aquí los escapa y te avisa cuando discrepa del built-in del navegador.

Ya no. HTML sugirió en su momento que los servidores aceptaran ; junto a & como separador de parámetros, y ese consejo se retiró de la especificación en 2014. Los navegadores y URLSearchParams nunca lo trataron como separador, así que a=1;b=2 es un único parámetro llamado a cuyo valor es el literal 1;b=2. Esta herramienta replica ese comportamiento y te avisa cuando ve un punto y coma, porque un backend heredado puede seguir partiendo por él y discrepar del navegador que tiene delante.

Sí: la herramienta completa es una página estática sin servidor detrás. Analizar, codificar y decodificar ocurre en la pestaña de tu navegador, nada se sube, no hay registros y no hay cuenta. Aquí importa más que en la mayoría de las herramientas, porque los query strings son justo donde acaban los tokens de acceso, las URLs firmadas, los ids de sesión y las direcciones de correo. Si quieres una segunda opinión, abre el panel de red de las herramientas de desarrollo mientras escribes: no hay ninguna petición que ver.