Erro 1: interpolar strings sem encodeURIComponent
encodeURIComponent() é a causa mais frequente de pedidos que falham silenciosamente ou devolvem erro 400.Um cenário hipotético comum: um programador júnior está a construir uma chamada a uma API de pesquisa e escreve algo como fetch(`/api/produtos?nome=${nomeProduto}`). Enquanto testa com valores simples como "mesa", tudo funciona. Assim que um utilizador pesquisa "mesa & cadeira" ou "sofá de 2 lugares", o & ou o acento partem a query string, e o servidor recebe um parâmetro truncado ou mal formado — o erro 400 aparece sem explicação óbvia no código.
O diagnóstico é rápido: cola o valor suspeito (ex.: sofá de 2 lugares) no separador "Codificar" desta ferramenta, escolhe o modo Componente, e compara o resultado com o que o teu código está realmente a enviar. Se forem diferentes, encontraste o problema — falta aplicar encodeURIComponent() a cada valor antes de o inserires no template da URL.
Erro 2: codificar duas vezes o mesmo valor
%2520 em vez de %20 — e o servidor de destino recebe um valor ilegível.
Isto acontece com frequência em arquiteturas com várias camadas: um frontend codifica um parâmetro antes de o enviar a um serviço intermédio, e esse serviço, sem saber que o valor já estava codificado, aplica encodeURIComponent outra vez antes de o reencaminhar. O carácter % em si é codificado como %25, por isso um %20 vira %2520.
%XX depois de uma primeira descodificação, é sinal de dupla (ou tripla) codificação — a opção multinível resolve todas as camadas de uma vez, para veres imediatamente o texto original.| Estado do valor (exemplo) | O que aparece | Diagnóstico |
|---|---|---|
| Codificado 1x | tenis%20de%20corrida | Normal — descodifica para texto legível |
| Codificado 2x | tenis%2520de%2520corrida | Dupla codificação — usar modo multinível |
| Não codificado | tenis de corrida | Falta aplicar encodeURIComponent antes de enviar |
Erro 3: tratar Base64 como se já fosse seguro para URL
+ e /, que têm significado próprio num URL — colocá-la diretamente num parâmetro sem aplicar depois encodeURIComponent arrisca corromper o valor no servidor de destino.
Um caso hipotético frequente: um token de autenticação ou um pequeno payload é gerado em Base64 e colocado diretamente como parâmetro de query, por exemplo ?token=abc+def/xyz==. Alguns servidores interpretam o + como espaço e o resultado é um token inválido do lado do servidor, mesmo que o Base64 original estivesse perfeitamente correto.
A prática recomendada, e o que esta ferramenta permite verificar diretamente no separador Base64: gera primeiro a cadeia Base64, depois aplica encodeURIComponent ao resultado antes de o colocares num link ou numa query string. Isto garante que o + vira %2B e o / vira %2F, preservando o valor exato até chegar ao destino.
Erro 4 e 5: query strings mal montadas e links não verificados antes de partilhar
Dois erros adicionais, mais frequentes em equipas com vários programadores ou em revisões de código apressadas:
- Concatenar parâmetros manualmente com "&" e "=". Escrever
url + "?a=" + valorA + "&b=" + valorBà mão é propenso a erro — falta um&, ou um valor com espaço não é codificado. No separador "Construir Query", introduz-se cada par chave-valor num campo próprio e a ferramenta trata da codificação e da junção automaticamente, tanto para gerar apenas a query string como um URL completo. - Partilhar um link sem verificar o que ele realmente contém. Antes de enviares um URL longo a um colega ou cliente — por exemplo, copiado de uma barra de endereços depois de várias redireções — cola-o no separador "Analisar URL" para veres o protocolo, o anfitrião, o caminho, a query e o fragmento decompostos, e no separador "Analisar Query" para veres cada parâmetro, com os de tracking assinalados.
Testa o teu parâmetro, token ou URL suspeito nos 6 modos da ferramenta — tudo processado no teu navegador, nada é enviado para um servidor.
Experimentar a ferramenta →Perguntas frequentes
Porque é que a minha chamada fetch/API devolve erro 400 com certos parâmetros?
/pesquisa?q=${termo}) sem passar o valor por encodeURIComponent primeiro. Se o termo contiver espaços, &, # ou acentos, o servidor recebe um URL malformado ou corta o parâmetro a meio, o que muitas APIs devolvem como erro 400 (Bad Request). Testa o valor no separador Codificar desta ferramenta antes de o colocares na chamada.Como sei se um parâmetro já está codificado, para não o codificar outra vez?
%XX no texto (ex.: %20, %C3%A9) — se já vês isso, o valor provavelmente já está codificado. Cola-o no separador Descodificar: se o resultado for texto legível sem símbolos % residuais, estava corretamente codificado uma vez. Se depois de descodificar ainda restarem %XX (por exemplo %2520), estava codificado duas vezes e precisas da opção de descodificação multinível.