Cole um JWT para ver o cabeçalho e o payload em JSON legível, com as datas dos claims exp, iat e nbf convertidas e o aviso se o token já expirou. A decodificação acontece só no seu navegador e não verifica a assinatura.
Exemplos fictícios:
O token é decodificado só no seu navegador e não é enviado nem guardado. Decodificar não verifica a assinatura: o conteúdo exibido pode ter sido alterado por qualquer pessoa.
Como usar
- Cole o token. Pode incluir o prefixo
Bearer, que é removido automaticamente. - Clique em Decodificar.
- Confira o resumo de tempo (emissão, início de validade, expiração), os alertas e os dois blocos JSON.
- Use os exemplos fictícios para ver um token válido, um expirado, um com
alg: nonee um malformado.
Estrutura de um JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjMiLCJleHAiOjE3NzI4OTc0MDB9 . assinatura
cabeçalho (Base64URL) payload (Base64URL) assinaturaSão três partes separadas por ponto. As duas primeiras são JSON codificado em Base64URL, e qualquer pessoa consegue lê-las. A terceira é a assinatura, calculada com uma chave secreta (HMAC) ou privada (RSA, ECDSA) sobre as duas primeiras.
Claims de tempo
| Claim | Significado |
|---|---|
exp | Momento a partir do qual o token não deve mais ser aceito. |
nbf | Momento antes do qual o token ainda não vale. |
iat | Momento em que o token foi emitido. |
Os três são em segundos desde 1970 (tempo Unix). A ferramenta mostra cada um em UTC, no seu fuso e em tempo relativo (“em 59 min”, “há 2 h”), e avisa se algum parece estar em milissegundos, um erro comum de implementação.
Decodificar não é validar
A ferramenta não tem, e não deveria ter, a chave de quem emitiu o token. Ela só lê o conteúdo. Um token alterado à mão aparece aqui decodificado normalmente. Quem garante a autenticidade é o servidor, que precisa verificar a assinatura com a chave correta, exigir o algoritmo esperado (nunca aceitar o que o próprio token declara) e checar exp, nbf, iss e aud.
Uso em QA e desenvolvimento
- Conferir se o token de um usuário de teste carrega os perfis e permissões esperados.
- Investigar erros 401 e 403: token expirado, emissor ou audiência errados, relógio do servidor fora de hora.
- Planejar casos de teste de segurança, como token expirado, assinatura adulterada,
alg: none, claims ausentes e tipos errados. - Validar tempos de sessão: a diferença entre
expeiatmostra a duração configurada.
Casos de teste sugeridos para APIs com JWT
| Cenário | Esperado |
|---|---|
| Token válido | 200 |
| Token expirado | 401 |
| Payload alterado sem reassinar | 401 |
alg trocado para none | 401 |
| Token de outro ambiente ou emissor | 401 |
| Token sem o perfil exigido pela rota | 403 |
| Sem cabeçalho Authorization | 401 |
Limitações
- Não verifica assinatura nem consulta o emissor.
- Não decodifica JWE (tokens criptografados com 5 partes): o conteúdo deles só pode ser lido com a chave.
- O cálculo de expiração usa o relógio do seu computador.
Perguntas frequentes
É seguro colar um token de produção aqui?
O token não sai do seu navegador e não é guardado. Mesmo assim, um token válido dá acesso à conta de alguém: prefira tokens de ambientes de teste e nunca compartilhe a tela ou o texto de um token ativo.
Se dá para ler o payload, o JWT é inseguro?
Não necessariamente. O JWT assinado garante integridade, não sigilo. Por isso não se deve colocar senhas ou dados sensíveis no payload.
Por que o token aparece como válido aqui, mas a API recusa?
A ferramenta só olha o prazo. A API pode recusar pela assinatura, pelo emissor, pela audiência, por revogação ou por diferença de relógio.
Ferramentas relacionadas
- Codificador e decodificador Base64: decodifique as partes manualmente.
- Conversor de timestamp Unix: converta outros campos de data.