🔑Decodificador de JWT
Cole um token JWT (JSON Web Token) para ver o conteúdo do Header e do Payload em JSON formatado, incluindo a data de expiração convertida para um formato legível.
⚠️ Esta ferramenta apenas decodifica e exibe o conteúdo — ela NÃO verifica a assinatura do token (isso exige o segredo ou a chave pública, que não estão disponíveis no navegador). Nunca confie em um JWT não verificado para decisões de autorização; a verificação precisa acontecer no servidor.
🔒 Cálculo 100% local — os dados que você digita não saem do seu navegador, nada é enviado a servidores.
Fonte: RFC 7519 (JSON Web Token) · RFC 4648 (Base64URL) — decodificação local via atob e TextDecoder; não realiza verificação criptográfica da assinatura · Última verificação em 23/09/2026
Um JWT tem três partes separadas por ponto: Header, Payload e Assinatura. Header e Payload são apenas JSON codificado em Base64URL — qualquer pessoa pode decodificá-los sem nenhuma chave, como esta ferramenta faz. A Assinatura é diferente: ela só pode ser gerada e conferida por quem possui o segredo (ou a chave privada), então decodificar um JWT nunca prova que ele é autêntico — isso exige verificação no servidor.
Como usar o decodificador
- Cole o token JWTO texto completo, no formato header.payload.assinatura, com exatamente dois pontos separando as três partes.
- Leia Header e PayloadAmbos aparecem como JSON formatado, com indentação de 2 espaços para facilitar a leitura de cada claim.
- Confira a expiraçãoSe o payload tiver a claim exp, a ferramenta converte o timestamp Unix para uma data legível e mostra se o token já expirou.
Como funciona a decodificação
Um JWT é composto por três segmentos separados por ponto: Header (metadados, como o algoritmo de assinatura), Payload (as claims, isto é, os dados do token) e Assinatura (um valor criptográfico calculado sobre os dois primeiros segmentos). Header e Payload são, cada um, um objeto JSON codificado em Base64URL — uma variante do Base64 onde os caracteres + e / são trocados por - e _ para o resultado ser seguro dentro de uma URL, e o caractere de preenchimento = normalmente é omitido.
Para decodificar cada segmento, a ferramenta reverte essa variante (troca - e _ de volta para + e /), adiciona o preenchimento = necessário para o comprimento ser múltiplo de 4, aplica `atob()` para obter a string binária, e então usa um `TextDecoder` sobre os bytes para reconstruir corretamente o texto em UTF-8 — um passo importante, porque claims em português com acentos (como um nome em "name") ficariam corrompidas com uma decodificação Base64 ingênua que não trata UTF-8 explicitamente. O resultado final é convertido de JSON para um objeto e reformatado com indentação.
Base64URL → Base64: troca - por + e _ por /, adiciona preenchimento =
Este decodificador NÃO verifica a assinatura
Este é o ponto mais importante sobre esta ferramenta: ela decodifica e exibe o conteúdo do Header e do Payload, mas não confere a Assinatura. Verificar a assinatura exige o segredo compartilhado (para algoritmos simétricos como HS256) ou a chave pública correspondente (para algoritmos assimétricos como RS256), e nenhum desses dados deveria estar disponível no navegador de quem está apenas inspecionando um token — se estivesse, o segredo teria vazado.
Na prática, isso significa que qualquer pessoa pode pegar um JWT, decodificá-lo, editar o Payload à vontade (por exemplo, mudando um campo "role":"user" para "role":"admin") e recodificá-lo — só não vai conseguir gerar uma Assinatura válida para o conteúdo alterado sem o segredo. Por isso, o conteúdo de um JWT decodificado aqui deve ser tratado apenas como leitura e depuração; nenhuma decisão de autorização, autenticação ou confiança pode se basear em um token cuja assinatura não foi verificada — e essa verificação só pode acontecer no servidor, onde o segredo ou a chave pública estão protegidos.
Suposições e limitações
- Decodifica apenas: não verifica a assinatura nem confirma que o token é autêntico ou não foi alterado
- Exige exatamente três segmentos separados por ponto (header.payload.assinatura); um token incompleto ou mal formado gera um erro claro
- Trata corretamente claims com acentos e caracteres UTF-8 no Payload, usando TextDecoder na decodificação
- A claim exp (quando presente) é interpretada como timestamp Unix em segundos, o padrão definido pela RFC 7519
- O token colado é processado inteiramente no navegador — mesmo assim, evite colar tokens de produção com dados sensíveis em ferramentas de terceiros sempre que possível
Dicas para tirar o melhor proveito
Use esta ferramenta para depurar rapidamente por que uma API está rejeitando um token: cole o JWT e confira se as claims esperadas (como `sub`, `role` ou `aud`) estão realmente presentes e com os valores certos, e se o token não expirou. Se o Payload parecer correto mas a API mesmo assim rejeitar, o problema provavelmente está na Assinatura ou no algoritmo declarado no Header (campo `alg`) — algo que esta ferramenta não consegue diagnosticar, já que não verifica a assinatura.
Preste atenção especial ao campo `alg` do Header: se ele estiver como "none", o token está usando uma configuração insegura (sem assinatura), aceita por algumas bibliotecas antigas por engano — isso é uma falha de segurança conhecida (JWT alg=none bypass) e nunca deveria ser aceito por um verificador em produção. Compare também `iat` (quando o token foi emitido) com `exp` (quando expira) para entender a janela de validade planejada pelo emissor.
Erros comuns a evitar
Confiar no conteúdo de um JWT decodificado sem verificar a assinatura — como um front-end lendo a claim `role` de um token só para decidir o que mostrar, sem que o back-end confirme de forma independente e criptográfica que aquele token é legítimo. Qualquer decisão de autorização real precisa da verificação da assinatura no servidor; usar o payload decodificado no navegador apenas para exibir informação (como o nome do usuário já autenticado por outro meio) é diferente de usá-lo para controlar acesso.
Outro erro é armazenar um JWT sensível (de produção, com dados reais de um usuário) em ferramentas online de terceiros por hábito — mesmo processando tudo localmente como esta ferramenta faz, é uma boa prática usar tokens de teste ou de exemplo ao depurar publicamente. Por fim, tratar um JWT expirado (`exp` no passado) como se ainda fosse válido: um token expirado deve ser rejeitado pelo verificador mesmo que a assinatura esteja correta, e o `exp` sozinho não impede um token de ser inspecionado ou decodificado — apenas sinaliza que ele não deveria mais ser aceito.
Veja também
Se esta ferramenta foi útil, você também pode precisar destas relacionadas: Conversor de Base64, Formatador e validador de JSON, Gerador de hash, Codificador e decodificador de URL.
Ferramentas relacionadas
🔤Conversor de Base64
Codifique ou decodifique texto em Base64, com suporte completo a acentos.
Abrir ferramenta →🧾Formatador e validador de JSON
Cole um JSON, formate com indentação, minifique ou descubra exatamente onde está o erro.
Abrir ferramenta →#️⃣Gerador de hash
Calcule hash MD5, SHA-1, SHA-256 e SHA-512 de um texto.
Abrir ferramenta →🔗Codificador e decodificador de URL
Codifique ou decodifique texto para usar com segurança em parâmetros de URL.
Abrir ferramenta →Perguntas frequentes
Esta ferramenta verifica se o JWT é válido/autêntico?
Não. Ela apenas decodifica e exibe o Header e o Payload, que são apenas Base64URL de JSON e podem ser lidos por qualquer pessoa sem nenhuma chave. Verificar a Assinatura exige o segredo ou a chave pública, que não estão disponíveis no navegador, e essa verificação precisa ser feita no servidor.
Por que meu token dá erro ao decodificar?
O erro mais comum é o token não ter exatamente três partes separadas por ponto (header.payload.assinatura), ou uma das partes não decodificar como JSON válido depois do Base64URL. Confira se copiou o token completo, sem cortes ou espaços extras.
O que significa a claim exp?
É a data de expiração do token, expressa como timestamp Unix em segundos (quantidade de segundos desde 1º de janeiro de 1970). A ferramenta converte esse número para uma data legível e indica se o token já expirou comparando com o horário atual.
Posso confiar no payload de um JWT que recebi de outro sistema?
Só depois de verificar a assinatura no servidor com o segredo ou a chave pública correta. Sem essa verificação, qualquer pessoa poderia ter editado o payload antes de te enviar o token — decodificar sozinho não prova autenticidade.
Por que claims com acentos aparecem corretas aqui?
Porque a decodificação usa TextDecoder para interpretar os bytes do Base64URL como UTF-8 corretamente. Uma decodificação Base64 ingênua, sem esse cuidado, corromperia caracteres acentuados presentes em claims como nomes.
É seguro colar um JWT de produção aqui?
O processamento é 100% local, sem envio a servidores, mas como boa prática geral evite colar tokens reais de produção com dados sensíveis em qualquer ferramenta online, mesmo local — prefira tokens de teste sempre que possível.
Explore mais ferramentas gratuitas
Dezenas de calculadoras, conversores e geradores — todos funcionam no navegador, sem cadastro e sem instalar nada.