Como usar
- Cole o token completo: três partes em Base64URL separadas por pontos.
- Leia o cabeçalho e o payload decodificados. As declarações exp, iat e nbf aparecem como datas, com um aviso quando o token está expirado ou ainda não é válido.
- Para verificar a assinatura, informe o segredo compartilhado em Chave secreta para HS256, HS384 ou HS512, ou cole a chave pública PEM em Chave pública (PEM, SPKI) para os algoritmos RS, PS ou ES.
- Confira se as declarações de emissor, público e assunto correspondem ao que a sua aplicação espera.
Como um JWT é formado
Um JSON Web Token (RFC 7519) tem três partes separadas por pontos: header.payload.signature. O cabeçalho e o payload são objetos JSON codificados em Base64URL sem preenchimento, e é por isso que os tokens quase sempre começam com eyJ, a forma codificada de um {" de abertura. A assinatura é calculada sobre as duas primeiras partes exatamente como aparecem no token.
- Cabeçalho: o algoritmo de assinatura em
alg, geralmente"typ": "JWT"e, muitas vezes, umkidque identifica a chave. - Payload: as declarações (claims), como quem é o usuário, quem emitiu o token e quando ele expira.
- Assinatura: uma assinatura HMAC, RSA ou ECDSA que comprova que o cabeçalho e o payload não foram alterados.
Um token com cinco partes é um JWE criptografado; o conteúdo dele não pode ser lido sem a chave de descriptografia.
Declarações registradas
| Declaração | Nome | Significado |
|---|---|---|
iss | Emissor | Quem criou e assinou o token |
sub | Assunto | A quem o token se refere, geralmente um ID de usuário |
aud | Público | O serviço ao qual o token se destina |
exp | Data de expiração | Depois desse momento, o token deve ser rejeitado |
nbf | Não antes de | Antes desse momento, o token deve ser rejeitado |
iat | Emitido em | Quando o token foi criado |
jti | ID do JWT | Identificador único, usado para detectar reutilização (replay) |
Os horários são valores NumericDate: segundos desde 1º de janeiro de 1970 UTC, e não milissegundos. O decodificador os exibe como datas legíveis e os compara com o relógio do seu dispositivo.
Decodificar não é verificar
Qualquer pessoa pode decodificar um JWT, porque o payload é apenas codificado, não criptografado; nunca coloque senhas ou outros segredos nele. A confiança vem somente da verificação da assinatura com a chave correta, e um servidor que aceita tokens também deve:
- permitir apenas o algoritmo esperado e rejeitar
"alg": "none", que indica um token sem assinatura; - nunca deixar o cabeçalho do token escolher entre HMAC e RSA, caso contrário um atacante pode assinar um token forjado usando a sua chave pública como segredo HMAC;
- verificar
exp,nbf,isseaudem todas as requisições.
A verificação opcional desta página usa a Web Crypto API integrada ao seu navegador. A decodificação e a verificação acontecem no seu dispositivo, e nada é enviado. Como regra geral, nunca cole chaves de assinatura de produção ou tokens em uso em sites nos quais você não confia.
Perguntas frequentes
É seguro colar um JWT neste decodificador?
O token é decodificado e verificado por JavaScript no seu navegador e nunca é enviado a um servidor. Lembre-se de que um token ainda não expirado funciona como uma senha para quem o tiver em mãos, então prefira tokens de teste ou expirados ao compartilhar capturas de tela ou logs.
Posso decodificar um JWT sem a chave secreta?
Sim. O cabeçalho e o payload são JSON comum codificado em Base64URL, então podem ser lidos sem nenhuma chave. A chave secreta ou pública só é necessária para verificar a assinatura.
Por que o decodificador diz que meu token expirou?
exp dele é anterior ao horário atual do seu dispositivo. Se o token ainda deveria ser válido, confira o relógio do sistema e o tempo de vida do token configurado pelo emissor.Quais algoritmos de assinatura podem ser verificados?
HS256, HS384 e HS512 com um segredo compartilhado, e RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 e ES512 com uma chave pública em formato PEM.
O que significa "alg": "none"?
Indica um JWT não protegido, com assinatura vazia, conforme definido na RFC 7518. Qualquer pessoa pode criar ou alterar um token assim, então um servidor que espera tokens assinados deve sempre rejeitá-lo.