Codificador/Decodificador de URL

Codifique texto para URL ou decodifique strings percent-encoded. Converta caracteres especiais, espaços e Unicode para uso em APIs e query strings.

Tem feedback? Reporte bugs, sugira recursos ou compartilhe suas ideias — lemos todos

Codificador/Decodificador de URL - Codificar e Decodificar URLs Online

Uma ferramenta poderosa online de codificação e decodificação de URL que ajuda você a codificar texto para uso seguro em URLs ou decodificar strings de URL percent-encoded de volta para texto simples. Possui manipulação automática de caracteres especiais, espaços, Unicode, e várias opções de codificação. Essencial para desenvolvedores web trabalhando com parâmetros de consulta, endpoints de API, dados de formulário, e manipulação de URL.

Por que a codificação de URL transforma um espaço em %20?

As URLs foram originalmente restritas a um pequeno conjunto de caracteres ASCII pela RFC 1738 (1994) e mais tarde RFC 3986 (2005), excluindo espaços porque eles quebram parsers que delimitam componentes com espaços em branco. Qualquer caractere que não esteja no conjunto não reservado (A-Z, a-z, 0-9, e -._~) deve ser codificado em porcentagem: o byte é escrito como % seguido por seu valor hexadecimal de dois dígitos. Um espaço é o byte 0x20, daí %20. No formato mais antigo application/x-www-form-urlencoded usado por formulários HTML, um espaço pode ser codificado como +. Ambas as formas decodificam de volta para espaço, mas não são intercambiáveis em todos os contextos: na query string, + comumente significa espaço, mas no path ou fragmento, + significa um + literal.

Qual a diferença entre encodeURI e encodeURIComponent?

Essas duas funções JavaScript codificam diferentes conjuntos de caracteres porque visam escopos diferentes. encodeURI assume que você está passando uma URL completa e preserva caracteres com significado estrutural: : / ? # [ ] @ ! $ & ' ( ) * + , ; = ~ permanecem como estão. encodeURIComponent assume que você está passando um valor de componente único (um segmento de path, um valor de query, um fragmento) que deve ser incorporável dentro de uma URL sem quebrar a sintaxe, então escapa todos esses caracteres estruturais também. Regra prática: construa o esqueleto da URL com encodeURI, mas sempre envolva cada valor fornecido pelo usuário com encodeURIComponent antes de concatenar. Usar encodeURI para valores de query é a causa mais comum de links de busca e rastreamento quebrados.

Por que encodeURIComponent não escapa ! * ' ( ) e como o torno estrito conforme RFC 3986?

O encodeURIComponent do JavaScript foi implementado conforme a especificação RFC 2396 mais antiga, que classificava ! * ' ( ) como marcas que não exigiam escape. RFC 3986 reclassificou-os como sub-delims reservados em alguns contextos. Para conformidade total com RFC 3986, pós-processe o resultado: encodeURIComponent(str).replace(/[!*'()]/g, c => '%' + c.charCodeAt(0).toString(16).toUpperCase()). Isso importa ao gerar assinaturas OAuth 1.0a (a spec exige codificação estrita), ao construir requisições canônicas AWS Signature V4, ou ao interoperar com bibliotecas estritas do lado do servidor. Para links web típicos, a função embutida do JavaScript serve. Esta ferramenta oferece um modo estrito que escapa o conjunto reservado completo conforme RFC 3986 seção 2.2.

Como caracteres não-ASCII como chinês, vietnamita ou emoji são codificados?

Conforme RFC 3986 seção 2.5 (e specs IRI anteriores na RFC 3987), texto não-ASCII em URLs deve primeiro ser convertido para bytes UTF-8 e depois cada byte codificado em porcentagem. O caractere "é" são dois bytes em UTF-8 (C3 A9), então torna-se %C3%A9 — dois escapes percentuais, não um. O emoji "🎉" são quatro bytes UTF-8 (F0 9F 8E 89) e torna-se %F0%9F%8E%89 — quatro escapes. Sistemas antigos às vezes usavam Latin-1 ou Windows-1252 e produziam %E9 para é, que um decodificador UTF-8 moderno interpretará erroneamente. Se você vir ? ou caracteres de substituição após decodificar, a origem provavelmente usou uma codificação de bytes não-UTF-8. Esta ferramenta sempre codifica e decodifica como UTF-8.

Codificador/Decodificador de URL — Codifique texto para URL ou decodifique strings percent-encoded. Converta caracteres especiais, espaços e Unicode para u — **Codificador/Decodificador de URL**

Quais caracteres nunca precisam ser codificados em uma URL?

RFC 3986 define o conjunto não reservado: A-Z maiúsculas, a-z minúsculas, dígitos 0-9, e as quatro marcas - . _ ~. Esses 66 caracteres têm garantia de significar o mesmo em todo componente de URL e nunca exigem codificação. Caracteres reservados dividem-se em dois grupos: gen-delims (: / ? # [ ] @) que separam componentes de URL e devem ser codificados dentro do valor de um componente, e sub-delims (! $ & ' ( ) * + , ; =) que têm significado especial em certos componentes. Se sub-delims precisam de codificação depende do contexto — = e & são críticos dentro de query strings mas inofensivos dentro de um segmento de path. Atalho seguro: codifique tudo fora do conjunto não reservado.

Por que a decodificação às vezes deixa um %25 literal na minha string?

Porque o próprio % deve ser codificado como %25 para distingui-lo da sequência de escape de codificação percentual. Se sua string continha um sinal de percentagem literal que foi corretamente codificado uma vez como %25, uma única passada de decodificação o transforma de volta em %. Mas se a string foi duplamente codificada — codificada uma vez ao armazenar, codificada novamente ao concatenar em outra URL — uma única decodificação deixa %25 no lugar, que então parece um escape perdido. Codificação dupla é comum em pipelines onde uma URL é passada como parâmetro de query para outro serviço: cada hop adiciona outra camada. A cura é decodificar exatamente uma vez por hop de codificação, nunca mais, nunca menos.

Fragmentos de URL (a parte após #) são codificados igual ao path ou query?

Principalmente, mas com duas diferenças-chave. RFC 3986 seção 3.5 define o alfabeto do fragmento como pchar / "/" / "?", o que permite / e ? não escapados dentro do fragmento sem ambiguidade (não há mais delimitadores após #). Isso significa que encodeURIComponent vai super-escapar esses caracteres em fragmentos, produzindo %2F e %3F onde as formas não escapadas são legais. Além disso, o fragmento nunca é enviado ao servidor em requisições HTTP — é puramente do lado do cliente — então decodificadores do lado do servidor podem nunca vê-lo. Ao construir fragmentos de deep-link para SPAs que contêm JSON ou rotas, o super-escape do encodeURIComponent geralmente está bem. Esta ferramenta expõe um modo consciente de fragmento.

Qual o comprimento máximo de uma URL, e o que acontece se eu exceder?

Não há limite rígido nas especificações HTTP ou URL — RFC 7230 recomenda explicitamente que servidores suportem "uma linha de requisição de pelo menos 8000 octetos". Na prática, navegadores, servidores e intermediários impõem seus próprios limites. Chrome aceita até 32 KB na barra de endereço mas trunca além de 2 MB internamente. Apache padrão é 8 KB (LimitRequestLine), Nginx 8 KB (large_client_header_buffers), e IIS 16 KB. AWS API Gateway limita em 8 KB. Além do limite do hop mais baixo, você obtém um erro 414 URI Too Long. Para dados acima de algumas centenas de bytes, mude para um corpo POST ou fragmente os dados em múltiplas requisições. Mantenha URLs abaixo de 2 KB para portabilidade.