URL

Relatório de validação

O que é o Validador de URL?

Você cola uma URL e recebe um relatório estruturado: ela está bem formada, como cada componente se apresenta e com o que se preocupar. O validador passa a URL pelo construtor URL nativo do navegador — que implementa o padrão WHATWG URL — e depois adiciona checagens por componente em cima.

Uma "URL válida" não é só uma que dá parse. Uma URL como http://10.0.0.5/admin?token=abc123 dá parse sem problema, mas tem três coisas que você provavelmente quer sinalizar: http:// em vez de https://, um IP literal como host e um token na query. O validador levanta as três como avisos, separados do veredicto pass/fail. As regras de sintaxe vêm da RFC 3986; as preocupações com nomes de host vêm da RFC 1034 e da experiência operacional.

A saída é JSON, então dá para canalizar para um script de CI ou um log de debug. Tudo roda no seu navegador — a URL nunca sai da sua máquina. Se você quer só decompor a URL em componentes sem a camada de validação, use o URL Parser. Nomes de domínio internacionalizados são tratados pelas regras IDNA.

Como usar o Validador de URL

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

Cole uma URL ou carregue o exemplo

Solte uma URL no painel da esquerda. Clique em Exemplo para carregar uma URL limpa, bem formada, com parâmetros codificados em porcentagem:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active

O validador atualiza enquanto você digita. Tente casos limite: URLs http://, hosts em IP literal, URLs com credenciais, hosts de rótulo único (sem TLD), domínios Punycode. Cada um levanta um aviso diferente.

Leia o relatório

O painel da direita mostra um relatório JSON com três campos de topo: isValid (se a URL deu parse), checks (status por componente — protocolo, hostname, porta, pathname) e warnings (apontamentos consultivos que não são erros de sintaxe mas que provavelmente importam).

Copie ou baixe

Clique em Copiar para mandar o relatório JSON para a área de transferência, ou Baixar para salvar como .json. Minificar compacta o relatório em uma linha só, se você precisar para uma entrada de log.

Quando você usaria isso de verdade

Auditar um arquivo de configuração antes do deploy

A config do seu serviço tem 40 URLs — endpoints de webhook, callbacks de OAuth, integrações de terceiros. Uma tem uma senha embutida de um teste esquecido, duas ainda apontam para hosts http:// de staging. Passar uma a uma pelo validador pega as três antes do release. Dependências do formato de URL também aparecem na spec do OAuth 2.0 para redirect URIs.

Revisar URLs enviadas por usuários em um formulário

Um usuário envia um campo "site" que acaba sendo example — sem protocolo, sem TLD, só uma palavra. Ou https://192.168.1.5 — parece válida, dá parse válida, mas você quase certamente não quer renderizar isso como link de perfil. O validador sinaliza os dois: aviso de TLD ausente no primeiro, aviso de IP literal no segundo.

Diagnosticar por que um redirect está falhando

Seu callback OAuth devolve 400 com "invalid redirect_uri." A URL parece ok no navegador. Você cola no validador e percebe: o caminho tem um espaço literal e seu provedor de auth compara strings byte a byte depois da canonicalização. O aviso ("path contains unencoded space") era a resposta.

Pegar um descompasso Punycode vs Unicode

Você esperava ver münchen.example.com no relatório e em vez disso viu xn--mnchen-3ya.example.com. Esse é o formato Punycode — o que vai pelo fio — e o validador sinaliza para você saber que a entrada original tinha caracteres não-ASCII. Útil quando o usuário em um bug report copiou e colou uma URL de um domínio IDN.

Dúvidas frequentes

O que "válida" significa aqui de verdade?

Duas camadas. isValid: true significa que o construtor URL do navegador aceita a entrada — ou seja, a sintaxe está bem formada segundo o padrão WHATWG URL. warnings é separado: coisas sintaticamente válidas mas que provavelmente não são o que você quer (protocolo inseguro, IP literal, credenciais embutidas, TLD ausente etc.). Uma URL pode ser válida e ainda assim ter avisos.

Ele checa se a URL realmente resolve para alguma coisa?

Não — isso exigiria uma requisição de rede, e esta ferramenta roda inteiramente no seu navegador, sem chamadas externas. O validador checa só sintaxe e heurísticas de superfície. Para checar alcançabilidade, use curl -I ou uma ferramenta de uptime dedicada.

Por que http://example.com aparece como aviso?

Porque em 2026 uma URL em texto plano é quase sempre um erro — navegadores modernos avisam o usuário antes de enviar formulários por http://, o artigo "why HTTPS matters" do Google cobre a versão longa, e domínios com HSTS preload se recusam a carregar por HTTP. O aviso é consultivo; se você realmente quer http:// (intranet legada, dev local), ignore.

E URLs relativas como /api/orders?

O construtor URL precisa de uma URL absoluta — sem uma base, ele não consegue determinar protocolo nem host. O validador devolve isValid: false com um erro claro nesse caso. Para validar uma URL relativa, prefixe primeiro com uma base como https://example.com.

Credenciais em URLs estão sempre erradas?

Quase sempre. A RFC 3986 §3.2.1 diz que credenciais em URLs estão depreciadas por motivos de segurança. Elas acabam no histórico do navegador, em logs de acesso do servidor e em caches de proxy. Navegadores modernos as removem em silêncio em colagens da área de transferência. O validador as sinaliza para você ter um registro explícito antes de elas vazarem para algum lugar onde não deveriam.

Ele se importa com domínios IDN?

Sim — o validador anota se o hostname está em forma Punycode (xn--...) ou em ASCII puro. Navegadores podem mostrar a forma Unicode aos usuários enquanto transmitem a Punycode pelo fio, o que é a origem dos ataques homógrafos IDN. Mostrar o Punycode é um sinal pequeno mas útil.

Outras ferramentas de URL & JSON

Validação é uma operação. Aqui está o que combina naturalmente com ela: