URL

Normalizada

¿Qué es el Normalizador de URL?

Dos URLs que son "la misma" pero que no coinciden al compararlas por culpa de las mayúsculas o del orden de la query es uno de esos errores que te roba media tarde. HTTPS://Example.com/page y https://example.com/page apuntan al mismo recurso, pero una comparación de cadenas dice que son distintas. El normalizador toma una URL y produce su forma canónica según la RFC 3986 §6 y el WHATWG URL Standard, de modo que dos URLs que significan lo mismo producen la misma cadena.

Las normalizaciones son las aburridas pero importantes: pasar a minúsculas el esquema y el host (según la RFC 3986 §6.2.2.1, no distinguen mayúsculas), eliminar los puertos por defecto (:443 en https, :80 en http), decodificar caracteres no reservados con codificación porcentual (%41 → A), ordenar los parámetros de la consulta alfabéticamente por clave, eliminar el fragmento vacío (# sin nada detrás) y resolver los segmentos . y .. de la ruta. El JSON de salida incluye la URL normalizada, la original y un array changes que enumera exactamente qué se ha reescrito, para que veas por qué dos URLs que parecían distintas son en realidad la misma.

Todo se ejecuta en tu navegador con la API URL estándar y URLSearchParams: sin servidor, sin logs. Si tu entrada ya es canónica, el array changes queda vacío y esa es la respuesta: nada que hacer. Útil como comprobación previa antes de publicar un sitemap o de fijar <link rel="canonical">.

Cómo usar el Normalizador de URL

Tres pasos. Cada uno se corresponde con un botón de esta página.

Pega una URL o carga el ejemplo

Pega una URL en el panel izquierdo. Pulsa Ejemplo para cargar una URL desordenada y realista: esquema y host en mayúsculas, puerto por defecto, parámetros de query revueltos, espacio con codificación porcentual y fragmento vacío. URL de ejemplo:

HTTPS://API.Shop.Example.com:443/v1/orders/?status=active&customer=Ava%20Chen&page=2#

Los nombres de dominio internacionalizados (IDN) se convierten a Punycode mediante el constructor URL: esa es la forma que viaja realmente por la red, según las reglas de normalización de URI. La parte userinfo (user:pass@host) se conserva si está presente.

Lee la salida

El panel derecho muestra un JSON con tres campos: normalized (la URL canónica), original (lo que pegaste, recortado) y changes: un array de entradas { rule, from, to } que enumera cada reescritura. Si changes está vacío, la URL ya era canónica.

Copia o descarga

Pulsa Copiar para enviar el JSON al portapapeles, o Descargar para guardarlo como archivo .json. Minificar compacta el JSON en una sola línea. Usa Limpiar en el panel de entrada para empezar de nuevo.

Cuándo lo vas a usar de verdad

Claves de caché y deduplicación en analítica

Tu panel de analítica ve Example.com/page y example.com/page como dos filas distintas. Tu caché de CDN también. Normaliza al entrar y el duplicado desaparece. Mismo truco si estás montando un acortador de URLs o una deduplicación de marcadores: guarda la forma normalizada como clave de búsqueda.

URLs canónicas para SEO

Los buscadores penalizan el contenido duplicado cuando la misma página es accesible por varias URLs. Tu etiqueta <link rel="canonical"> y las URLs de tu sitemap.xml deben coincidir con una única forma normalizada. La guía de canonicalización de Google detalla las reglas; esta herramienta es la forma más rápida de aplicarlas a mano.

Comparar dos URLs por igualdad

Estás escribiendo un detector de bucles de redirección o probando un webhook. Dos URLs son "iguales" si sus formas normalizadas coinciden. Compara cadenas después de normalizar; no improvises tu propia función de igualdad basada en URL.toString(), porque eso no ordena los parámetros ni elimina los puertos por defecto.

Limpiar URLs antes de guardarlas o mostrarlas

Un usuario pega HTTPS://www.SHOP.com:443/cart/?b=2&a=1# en tu formulario. No quieres guardar eso en la base de datos y desde luego no quieres enviárselo por email. Normaliza primero y luego guarda la versión limpia. Las URLs que ven los clientes pasan a ser predecibles.

Preguntas frecuentes

¿Y si mi URL ya es canónica?

Verás la misma URL en normalized y en original, y el array changes estará vacío ("changes": []). Esa es la respuesta: no había nada que reescribir. La página no lanza errores en ese caso.

¿Toca la ruta más allá de quitar la barra final de la raíz?

Casi nada. Los segmentos . y .. se resuelven (lo hace el constructor URL automáticamente: la RFC 3986 §5.2.4 lo llama "remove dot segments"). Las barras finales solo se eliminan cuando la ruta es solo /; /v1/orders/ se queda como /v1/orders/ porque la RFC 3986 dice que las barras finales pueden ser significativas. Hay frameworks de servidor que las tratan como rutas distintas.

¿Por qué se ordenan mis parámetros de consulta? El orden me importa.

En la RFC 3986 el orden de la query no es semánticamente significativo: ?a=1&b=2 y ?b=2&a=1 son equivalentes a nivel de URL. Ordenar alfabéticamente te da una forma canónica estable para que dos URLs equivalentes coincidan byte a byte. Si tu aplicación realmente depende del orden de los parámetros (no debería, pero los sistemas heredados lo hacen), este normalizador rompe esa suposición: no normalices URLs que vayan a un servidor al que le importe el orden.

¿Por qué a veces %20 se convierte en + después de normalizar?

Tanto %20 como + representan un espacio dentro de una query string (según las reglas de application/x-www-form-urlencoded, que es lo que usa URLSearchParams al serializar). Cuando el objeto URLSearchParams vuelve a serializar la query, usa +. Son semánticamente idénticos para cualquier parser de URL conforme al estándar; si tu servidor los trata distinto, eso es un bug del servidor.

¿Qué pasa con dominios internacionalizados como café.example?

El constructor URL convierte el host a Punycode: caf%C3%A9.example pasa a ser xn--caf-dma.example. Esa es la forma con la que la URL se enviaría realmente por DNS, y es lo que indican la RFC 3987 y la especificación WHATWG. El artículo de Wikipedia sobre normalización de URI repasa el manejo de IDN si te interesa el detalle.

¿Es seguro con URLs que llevan credenciales (user:pass@host)?

El parseo ocurre íntegramente en tu navegador: nada se envía a ningún sitio. La parte userinfo se conserva durante la normalización. Otra cuestión es si deberías estar pasando credenciales por URL: la mayoría de navegadores y clientes HTTP las eliminan o avisan por los riesgos de seguridad, y casi siempre conviene más una cabecera Authorization.

¿Elimina parámetros de consulta duplicados?

No. ?tag=red&tag=red se queda como ?tag=red&tag=red. Las claves repetidas pueden tener sentido (algunas APIs las usan para arrays) y eliminarlas cambiaría la semántica. La ordenación es estable, así que dentro de una misma clave se conserva el orden original.

Otras herramientas de URL y JSON

Normalizar es una operación. Esto es lo que combina bien con ella: