Codificador e Decodificador de URL
Codifique um valor, uma URL inteira, ou decodifique qualquer um deles.
Parâmetros da query
- Tudo gratuitoSem conta, sem cota diária, sem plano pago.
- Nada é enviadoOs arquivos são processados no seu dispositivo e nunca chegam a um servidor.
- Sem pegadinha no resultadoSem marca d'água, sem redução forçada, sem limite de tamanho.
- Mudanças à vistaCada correção e cada ferramenta nova ficam registradas na página de novidades.
O que esta ferramenta faz
URLs só podem conter um conjunto limitado de caracteres ASCII. Qualquer outra coisa — espaços, caracteres chineses, &, =, ?, # e a maioria das pontuações — precisa ser codificada em porcentagem como bytes %XX antes de poder viajar com segurança em um link, um envio de formulário ou uma chamada de API. Esta página faz essa codificação nos dois sentidos e, diferente da maioria dos codificadores, também detalha o resultado: cole qualquer URL ou query string e os parâmetros aparecem como uma tabela decodificada de chave-valor, para você ler um link de rastreamento ou um redirecionamento OAuth num relance.
O texto é tratado como UTF-8, então 中文 vira %E4%B8%AD%E6%96%87 exatamente como navegadores e servidores esperam. A decodificação é tolerante: um % perdido que não seja um escape válido é deixado como está, em vez de gerar um erro, e o + é tratado como espaço quando você está decodificando dados de formulário.
Codificação de componente vs. de URL inteira
Codificar componente é o encodeURIComponent do JavaScript: ele escapa tudo, exceto letras, dígitos e -_.!~*'(). Use-o para um único valor que vai em um parâmetro de query, um segmento de caminho ou um campo de formulário. Codificar URL é o encodeURI: ele deixa intactos os caracteres estruturais :/?#[]@!$&'()*+,;= para que um endereço completo continue sendo um endereço válido, e escapa apenas espaços e texto não ASCII. Usar o errado é o bug clássico — encodeURIComponent em uma URL completa transforma cada / em %2F e quebra o link, enquanto encodeURI em um valor que contém & silenciosamente o divide em dois parâmetros.
A opção Espaço como + alterna entre %20 (RFC 3986, usado em URLs) e + (application/x-www-form-urlencoded, usado em corpos de formulários HTML e em muitas query strings legadas). Ambos decodificam corretamente aqui; escolha a codificação que o seu destino espera.
Erros comuns
Codificação dupla: codificar um valor já codificado transforma %20 em %2520 e o servidor vê um %20 literal. Se a sua saída decodificada ainda contém sequências %XX, decodifique mais uma vez. Esquecer de codificar & ou # dentro de um valor trunca o parâmetro. Codificar a URL inteira com encodeURIComponent quebra o esquema e as barras. Misturar as convenções + e %20 entre cliente e servidor produz sinais de mais em nomes de usuário. Por fim, a codificação em porcentagem não é criptografia nem ofuscação — um valor fica totalmente legível depois de decodificado, então nunca conte com ela para esconder tokens; se você precisa de opacidade para um payload, o Base64 é a codificação de transporte usual, e ele também é trivialmente reversível.
Contexto: de onde vem a codificação em porcentagem
A codificação em porcentagem foi definida com a primeira especificação de URL, a RFC 1738 (1994), escrita por Tim Berners-Lee e colegas, e refinada na RFC 3986 (2005), que é o padrão atual para a sintaxe de URI. O mecanismo de escape % é anterior à dominância do UTF-8, e é por isso que sistemas mais antigos às vezes codificam bytes em Latin-1 ou Shift-JIS e produzem mojibake quando decodificados como UTF-8 — o HTML5 URL Standard (WHATWG) finalmente exigiu UTF-8 para novas codificações. A convenção do + para espaço vem da especificação separada de formulários HTML, não do padrão de URL, que é a razão histórica de duas codificações de espaço coexistirem hoje.
Onde é usado
Montar requisições de API à mão (termos de busca, filtros, URLs de callback), depurar links de rastreamento de plataformas de anúncios (utm_source, gclid, fbclid), ler redirecionamentos de OAuth e SSO (redirect_uri, state, scope), construir links mailto: e tel: com assuntos e corpos, compartilhar links que contêm caminhos em chinês ou japonês, e inspecionar payloads de webhook enviados como dados de formulário. A tabela de parâmetros é prática para colar uma URL longa de um chamado de suporte e ver exatamente o que foi requisitado. Valores dentro de uma query string muitas vezes são JSON ou Base64 — decodifique aqui primeiro e depois cole o valor na ferramenta correspondente.
Perguntas frequentes
Qual é a diferença entre encodeURI e encodeURIComponent?
O encodeURIComponent escapa tudo, exceto os caracteres não reservados, e é para valores individuais. O encodeURI mantém os caracteres de estrutura da URL (/ ? & = # :), então é para endereços completos. Nunca aplique encodeURIComponent a uma URL inteira.
Um espaço deve ser %20 ou +?
%20 em URLs (RFC 3986). O + só dentro de corpos de formulário application/x-www-form-urlencoded e query strings que seguem a convenção de formulários HTML. Ambos decodificam como espaço aqui.
Por que meu texto decodificado contém %2520?
O valor foi codificado duas vezes. Decodifique-o de novo para obter o texto original.
Isto lida com chinês e emoji?
Sim. O texto é codificado como bytes UTF-8, então cada caractere chinês vira três sequências %XX e a maioria dos emojis vira quatro.
Algo é enviado para um servidor?
Não. Codificação, decodificação e leitura de query rodam inteiramente no seu navegador.