URL

Normalizada

O que é o Normalizador de URL?

Duas URLs que são "a mesma" mas que comparam-diferente por causa da capitalização ou da ordem da query é um daqueles bugs que toma uma tarde inteira. HTTPS://Example.com/page e https://example.com/page apontam para o mesmo recurso, mas uma comparação de string diz que são diferentes. O normalizador pega uma URL e produz a forma canônica conforme a RFC 3986 §6 e o WHATWG URL Standard, então duas URLs com o mesmo significado produzem a mesma string.

As normalizações são as chatas-mas-importantes: passar esquema e host para minúsculas (pela RFC 3986 §6.2.2.1, são case-insensitive), remover portas padrão (:443 em https, :80 em http), decodificar caracteres não reservados percent-encoded (%41 → A), ordenar parâmetros de consulta alfabeticamente por chave, retirar fragmento vazio (# sem nada depois) e resolver segmentos . / .. do caminho. O JSON de saída inclui a URL normalizada, a original e um array changes listando exatamente o que foi reescrito — assim você vê por que duas URLs que pareciam diferentes são na verdade a mesma.

Tudo roda no seu navegador usando a API URL padrão e o URLSearchParams — sem servidor, sem logs. Se a entrada já for canônica, o array changes fica vazio e essa é a resposta: nada a fazer. Útil como verificação rápida antes de publicar um sitemap ou definir <link rel="canonical">.

Como usar o Normalizador de URL

Três passos. Cada um corresponde a um botão desta página.

Cole uma URL ou carregue o exemplo

Solte uma URL no painel da esquerda. Clique em Exemplo para carregar uma URL realista e bagunçada — esquema e host em maiúsculas, porta padrão, ordem de query embaralhada, espaço percent-encoded, fragmento vazio. URL de exemplo:

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

Nomes de domínio internacionalizados (IDN) são convertidos para Punycode pelo construtor URL — é a forma que de fato vai pela rede, conforme as regras de normalização de URI. Userinfo (user:pass@host) é preservado se estiver presente.

Leia a saída

O painel da direita mostra um JSON com três campos: normalized (a URL canônica), original (o que você colou, sem espaços extras) e changes — um array de entradas { rule, from, to } listando cada reescrita. Se changes estiver vazio, a URL já era canônica.

Copie ou baixe

Clique em Copiar para mandar o JSON para a área de transferência, ou em Baixar para salvá-lo como arquivo .json. Minificar compacta o JSON em uma linha. Use Limpar no painel de entrada para começar de novo.

Quando você realmente vai usar isso

Chaves de cache e deduplicação no analytics

Seu painel de analytics vê Example.com/page e example.com/page como duas linhas diferentes. O cache do seu CDN também. Normalize na entrada e o duplicado some. Mesmo truque se você está montando um encurtador de URL ou um deduplicador de favoritos — guarde a forma normalizada como chave de busca.

URLs canônicas para SEO

Buscadores penalizam conteúdo duplicado quando a mesma página é alcançável em várias URLs. Sua tag <link rel="canonical"> e as URLs do sitemap.xml devem bater com uma única forma normalizada. O guia de canonização do Google detalha as regras; esta ferramenta é o jeito mais rápido de aplicá-las na mão.

Comparar duas URLs por igualdade

Você está escrevendo um detector de loop de redirect ou testando um webhook. Duas URLs são "a mesma" se as formas normalizadas combinam. Compare strings depois de normalizar — não invente sua própria função de igualdade baseada em URL.toString(), porque ela não ordena parâmetros nem remove portas padrão.

Limpar URLs antes de armazenar ou exibir

Um usuário cola HTTPS://www.SHOP.com:443/cart/?b=2&a=1# no seu formulário. Você não quer guardar isso no banco e definitivamente não quer mandar de volta por email. Normalize primeiro, depois salve a forma limpa. URLs visíveis ao cliente ficam previsíveis.

Perguntas frequentes

E se minha URL já estiver canônica?

Você verá a mesma URL em normalized e em original, e o array changes ficará vazio ("changes": []). Essa é a resposta — não havia o que reescrever. A página não lança erro nem mostra mensagem de falha nesse caso.

Mexe no caminho além de remover a barra final da raiz?

Quase nada. Segmentos . e .. são resolvidos (o construtor URL faz isso automaticamente — a RFC 3986 §5.2.4 chama de "remove dot segments"). Barras finais só são removidas quando o caminho é apenas /; /v1/orders/ continua /v1/orders/ porque a RFC 3986 diz que barras finais podem ser significativas. Frameworks de servidor podem tratá-las como rotas distintas.

Por que meus parâmetros de consulta estão sendo ordenados? Eu me importo com a ordem.

Na RFC 3986, a ordem da query não é semanticamente significativa — ?a=1&b=2 e ?b=2&a=1 são equivalentes no nível da URL. Ordenar alfabeticamente dá uma forma canônica estável, para que duas URLs equivalentes batam byte a byte. Se sua aplicação realmente depende da ordem dos parâmetros (não deveria, mas sistemas legados dependem), este normalizador quebra essa suposição — não normalize URLs que vão para um servidor que se importa com a ordem.

Por que %20 às vezes vira + depois da normalização?

Tanto %20 quanto + significam um espaço dentro de uma query string (pelas regras de application/x-www-form-urlencoded, que é o que o URLSearchParams usa para serializar). Quando o objeto URLSearchParams reserializa a query, ele usa +. São semanticamente idênticos para qualquer parser de URL conforme aos padrões; se seu servidor trata diferente, é um bug do servidor.

O que acontece com domínios internacionalizados como café.example?

O construtor URL converte o host para Punycode — caf%C3%A9.example vira xn--caf-dma.example. Essa é a forma com que a URL seria de fato enviada via DNS, e é o que a RFC 3987 / a especificação WHATWG determinam. O artigo da Wikipédia sobre normalização de URI explica o tratamento de IDN se você quiser os detalhes.

É seguro com URLs com credenciais (user:pass@host)?

O parsing acontece inteiramente no seu navegador — nada é enviado para lugar nenhum. Userinfo é preservado durante a normalização. Se você deveria estar passando credenciais numa URL é outra história — a maioria dos navegadores e clientes HTTP hoje retira ou avisa sobre userinfo por causa dos riscos de segurança, e geralmente é melhor usar um header Authorization.

Remove parâmetros de consulta duplicados?

Não. ?tag=red&tag=red continua ?tag=red&tag=red. Chaves repetidas podem ter significado (algumas APIs usam para arrays) e remover duplicatas mudaria a semântica. A ordenação é estável, então dentro da mesma chave a ordem original é preservada.

Outras ferramentas de URL e JSON

Normalizar é uma operação. Aqui está o que combina naturalmente com isso: