Decodificador de JWT
Cole um token JWT para ver o header, o payload e a assinatura, saber se ele ainda vale e conferir roles e scopes. A decodificação acontece enquanto você cola.
O token, o secret e a chave pública ficam no seu navegador. Nada disso é enviado para servidor nenhum, nem para o nosso, e some quando você fecha a página.
Nenhum token ainda
Cole um JWT no campo do token. O status, as datas e as claims aparecem aqui na hora.
Precisa de um token com outras claims, como um admin e um usuário comum?
Como usar o Decodificador de JWT?
Cole o token
Copie do DevTools, do Postman ou de um log e cole. Bearer, aspas e quebras de linha são removidos sozinhos.
Veja o status
O status mostra se o token expirou, quando expira e em que horário, no seu fuso e em UTC.
Confira a assinatura
Informe o secret ou a chave pública para saber se o token é autêntico e não foi alterado.
Copie o que precisar
Copie o token limpo, o header, o payload ou o valor de uma claim com um clique.
O que é um JWT?
JWT (JSON Web Token, RFC 7519) é um formato de token usado para transportar informações entre sistemas, principalmente em login e autorização de APIs. O servidor de autenticação emite o token depois do login, a aplicação envia esse token a cada requisição, e a API lê as claims para saber quem é o usuário e o que ele pode fazer.
As três partes de um JWT
Um JWT tem três trechos em base64url separados por ponto:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGVzIjpbInVzZXIiXX0.3mG4X8mY2bJqS0mY7fUv0M1wS6Qy0p2WmH0x0J3bQKc- Header. O header diz qual algoritmo assinou o token (alg) e, às vezes, qual chave foi usada (kid).
- Payload. O payload traz as claims: quem é o usuário, quando o token expira, para qual API ele vale e quais permissões tem.
- Assinatura. A assinatura é calculada sobre o header e o payload. Se qualquer caractere mudar, ela deixa de bater.
Por que dá para ler o payload sem senha
Header e payload são só codificados em base64url, uma variação do Base64 que troca + e / por - e _ e dispensa o = no final. Codificar não é criptografar: qualquer pessoa com o token lê o conteúdo, e é isso que esta ferramenta faz. Por isso, nunca coloque senha, número de cartão ou dado sensível no payload de um JWT.
Claims registradas e claims customizadas
A RFC 7519 define sete claims registradas: iss, sub, aud, exp, nbf, iat e jti. Elas têm nome curto e significado fixo, e as bibliotecas de JWT validam exp, nbf e aud automaticamente. O resto são claims customizadas, criadas pela aplicação ou pelo provedor de identidade, como roles, scope, email ou realm_access no Keycloak. Na tabela de claims, cada claim conhecida vem com uma explicação curta.
Decodificar não é validar
Ler o payload não prova nada sobre o token. Qualquer pessoa pode montar um JWT com sub de admin e exp daqui a dez anos. O que garante a autenticidade é a assinatura, e quem deve verificá-la é o backend, sempre com o algoritmo fixado na configuração, e não com o que vier no header. Use a verificação desta página para depurar, e nunca como substituta da validação no servidor.
O risco do alg none
O valor "none" em alg indica um token sem assinatura. Algumas bibliotecas antigas aceitavam esse token quando o header pedia, e um atacante só precisava trocar o alg e apagar a assinatura para se passar por qualquer usuário. Quando esta ferramenta encontra alg none, ela mostra um alerta. Se sua API aceitar um token assim, trate como falha de segurança.
JWS e JWE: assinado ou criptografado
Quase todo JWT que circula por aí é um JWS: assinado, com três partes e payload legível. O JWE é a versão criptografada, com cinco partes, e o conteúdo só pode ser lido por quem tem a chave de decriptação. Se você colar um JWE aqui, a ferramenta avisa e mostra só o header, que continua legível.
Onde encontrar o token para colar aqui
- No header Authorization: Bearer de uma requisição, na aba Network do DevTools ou no Postman e no Insomnia
- Em um cookie de sessão, na aba Application do DevTools (o cookie pode ser HttpOnly e não aparecer para o JavaScript)
- Na resposta do endpoint de token do provedor, nos campos access_token e id_token
- Em logs de API gateway e de aplicação, muitas vezes quebrado em várias linhas
Problemas comuns ao depurar login e permissão
Login que falha com 401 depois de um tempo
O status mostra se o exp já passou e há quanto tempo. Se o token expira em poucos minutos, confira se o front está usando o refresh token para pedir um novo.
Usuário recebe 403 mesmo logado
Veja o bloco de roles e scopes. Se a role esperada não está lá, o problema está na configuração do provedor ou no tipo de token enviado (ID token no lugar de access token é um erro comum).
Token recusado logo depois de emitido
exp, iat e nbf são contados em segundos UTC e não dependem de fuso. Quando um token novo é recusado, a causa costuma ser relógio desajustado entre servidores. As datas aparecem no seu horário e em UTC para facilitar a comparação com os logs.
Token válido, mas recusado por outra API
Confira o aud. Cada API deve aceitar só tokens emitidos para ela, então um token de uma API não serve para outra.
Perguntas Frequentes sobre o Decodificador de JWT
O que costuma aparecer ao ler e depurar tokens JWT.