Codificador e decodificador de URL

O que é codificação de URL

URLs são restritas a um pequeno conjunto de caracteres ASCII. O RFC para sintaxe de URL — RFC 3986 — reserva um punhado de caracteres (/, ?, #, &, =, etc.) para significado estrutural e proíbe espaços, caracteres de controle e a maioria de bytes não-ASCII de aparecer literalmente. Codificação de URL (também chamada codificação de percentual) é o mecanismo de escape: cada byte proibido é substituído por % seguido por seu valor hexadecimal de dois dígitos.

Portanto, um espaço se torna %20, um ampersand %26, um caractere chinês 世 se torna %E4%B8%96 (seus três bytes UTF-8, cada um percent-encoded). O resultado é sempre ASCII-safe.

encodeURIComponent vs encodeURI

JavaScript expõe duas funções diferentes, e elas não são intercambiáveis:

• encodeURIComponent codifica tudo que não é um caractere não reservado. Use isso para uma peça de uma URL — um valor de parâmetro de consulta, um segmento de caminho, um campo de formulário.
• encodeURI preserva caracteres estruturais de URL (:/?#&=+$,) na suposição de que você está entregando uma URL completa, já estruturada. Use isso quando você tem uma URL completa com conteúdo não-ASCII e quer torná-la transport-safe sem quebrar sua estrutura.

Exemplo de escolha errada: se você encodeURI("a=1&b=2"), o = e & são preservados como está — OK se essa string é uma consulta, quebrada se é um valor destinado a conter = ou & literal.

Esta ferramenta oferece ambas, além de um modo de decodificação que aceita ambos os sabores.

A pegadilha +

Historicamente, formulários HTML codificam espaços como + (este é o tipo MIME application/x-www-form-urlencoded). Padrões de URL modernos codificam espaços como %20. Ambos estão por aí — ao decodificar uma string de consulta, você deve aceitar ambos. Nosso decodificador faz.

Quando codificando, sempre emitimos %20 (o padrão moderno). Não emita + para espaços a menos que você especificamente precise de compatibilidade form-encoded.

Exemplos

Quando você usará isso

• Construindo strings de consulta programaticamente sem um roteador/biblioteca.
• Inspecionando uma URL codificada que alguém colou para você.
• Debugando "por que meu backend vê + em vez de espaço?"
• Gerando URLs canônicas em sitemaps e <link rel="canonical">.

Privacidade

100% no navegador via nativas funções encodeURIComponent / decodeURIComponent. Nenhuma solicitação de rede, nenhum log.

Ferramentas relacionadas

• Base64 Encoder — codificação diferente, geralmente encadeada com codificação de URL para transporte compacto.
• Slugify — transformar texto arbitrário em slugs de URL segura (uma operação de nível mais alto do que codificação simples).

Quando devo usar encodeURIComponent vs encodeURI?

encodeURIComponent para uma peça única (valor de consulta, segmento de caminho, campo de formulário). encodeURI para uma string URL completa que você não quer quebrar a estrutura. Quando em dúvida, use encodeURIComponent em cada peça e monte manualmente.

Por que meu valor decodificado tem + onde espaços deveriam estar?

Porque foi codificado por um codificador de formulário em vez de um codificador de URL, e esta ferramenta deliberadamente deixa sozinho. Formulários HTML codificam espaços como + sob o tipo MIME application/x-www-form-urlencoded, mas essa convenção se aplica apenas dentro de uma string de consulta codificada em formulário — em qualquer outro lugar em uma URL, + é um caractere literal ordinário. Um decodificador geral que silenciosamente transformasse cada + em espaço corromperia qualquer caminho ou valor que legitimamente contenha um.

Portanto, decodificar hello+world aqui retorna hello+world, enquanto hello%20world retorna hello world. Se sua entrada realmente é uma string de consulta codificada em formulário, substitua + por %20 antes de decodificar, ou por um espaço depois.

Como codifico caracteres especiais em chaves versus valores?

Ambos. Codifique cada chave e cada valor independentemente com encodeURIComponent, depois una com = e &. O modo "build query" nesta ferramenta faz exatamente isso.

Qual é o comprimento máximo de uma URL?

A especificação não tem limite, mas na prática ~2.000 caracteres é o teto seguro em navegadores + servidores + proxies. Para payloads mais longas, use um corpo POST em vez disso.

Meus dados são enviados em algum lugar?

Não. A página usa funções nativas do navegador para tudo. Abra DevTools Network — você verá zero solicitações enquanto digita.

Por que café produz seis bytes quando codificado?

é é dois bytes em UTF-8 (0xC3 0xA9), portanto percent-encodes para %C3%A9 — seis caracteres. ASCII de byte único como a permanece como um caractere.