Guia da ferramenta

Sobre Codificador/decodificador de URL

Um codificador e decodificador de URL transforma caracteres inseguros ou reservados em percent encoding e decodifica strings para texto legível.

Use para query parameters, caminhos com caracteres não ingleses, callback URLs e fragmentos copiados de logs. Tudo roda localmente no navegador.

Como usar o URL Encoder/Decoder

Cole uma URL completa, um valor de query parameter ou o texto que precisa codificar.
Clique em Encode para transformar espaços, texto não inglês e símbolos em percent encoding seguro.
Clique em Decode para transformar strings como %E4%B8%AD%E6%96%87 em texto legível.
Se apenas um parâmetro precisa de encoding, codifique o value e não o query string inteiro para preservar & e =.

Quando usar

Codificar termos de busca, callback URLs ou redirect parameters antes de colocar em URL, evitando que &, ? e # quebrem o parâmetro.
Decodificar paths ou query strings percent-encoded vindos de logs de API.
Depurar double encoding em OAuth redirect_uri, webhook callbacks ou links compartilhados.
Comparar a saída do encodeURIComponent no frontend com o valor recebido pelo backend.

Percent encoding, parâmetros URL e armadilhas comuns

Alguns caracteres de URL têm significado estrutural, como ?, &, =, # e /. Percent encoding escreve bytes como %HH para que eles viajem como dados, não como estrutura de URL.

Espaços: normalmente viram %20; em form encoding também pode aparecer +.
Texto não inglês e emoji: primeiro viram bytes UTF-8 e depois sequências percent.
encodeURI vs encodeURIComponent: encodeURI preserva caracteres estruturais; encodeURIComponent é melhor para um valor de parâmetro.
Double encoding: %25E4 costuma indicar que um sinal percent existente foi codificado de novo.

Perguntas frequentes sobre Codificador/decodificador URL

Codifico a URL inteira ou um parâmetro?: Normalmente codifique um valor de parâmetro. Codificar a URL inteira também escapa : / ? & e pode quebrar a interpretação do link.
Por que espaço aparece como %20 ou +?: %20 é percent encoding geral. O sinal + é comum em application/x-www-form-urlencoded.
Por que ainda há percent após decode?: Pode ser double encoding ou o valor original contém percent literal. Faça decode de novo apenas se tiver certeza de que é double-encoded.
URL-safe Base64 ainda precisa de URL encoding?: Geralmente precisa menos porque evita + e /. Mesmo assim confira padding = ou outros caracteres especiais antes de usar em query string.
Minha entrada é enviada?: Não. Encoding e decoding rodam localmente no navegador e não são enviados ao wetool.site.

Codificação de URL vs Base64

URL encoding torna caracteres seguros dentro de URLs. Base64 representa bytes como texto. Tokens, imagens e payloads binários podem envolver os dois, mas para fins diferentes.

encodeURI vs encodeURIComponent

Muitos bugs de URL encoding surgem ao tratar uma URL inteira e um valor de parâmetro como se fossem iguais.

URL inteira: a semântica encodeURI mantém : / ? & = # como estrutura, adequada para um link já montado.
Valor de parâmetro: encodeURIComponent codifica &, =, ? e #, adequado para search, redirect_uri, callback e valores parecidos.
Regras de formulário: application/x-www-form-urlencoded costuma escrever espaços como +; percent encoding geral normalmente usa %20.

Checklist de debug de URL encoding

Quando o backend recebe o parâmetro URL errado, confira quantas vezes o navegador, o frontend, o gateway e o framework do backend codificam ou decodificam o valor.

%25 geralmente indica que um sinal % existente foi codificado de novo, então double encoding é provável.
Se redirect_uri contém seu próprio query string, os ?, & e = internos precisam ser codificados como dados.
Não coloque input decodificado do usuário direto em HTML ou redirect URLs; mantenha allowlist de protocolo e escaping de saída.