Decodificar JWT
O Decodificador de JWT lê o header e o payload de um JSON Web Token no seu navegador e explica o que encontrou: o algoritmo de assinatura, cada claim com o seu significado e a expiração decodificada em uma data real. Ele nunca verifica a assinatura, porque isso exigiria enviar o seu token a quem detém a chave.
Como funciona o Decodificar JWT?
Um JSON Web Token é formado por três segmentos codificados em base64url e unidos por pontos: header.payload.signature. Os dois primeiros são objetos JSON, e não estão criptografados — base64url é uma codificação, não uma cifra. Qualquer pessoa com o token pode ler todas as claims nele, e é por isso que colocar uma senha, um número de cartão ou um ID interno de banco de dados em um payload de JWT é um erro que as pessoas cometem com regularidade e descobrem tarde.
Decodificar, portanto, é direto: divida nos pontos, decodifique base64url os dois primeiros segmentos, interprete cada um como JSON. O cuidado está nos detalhes que quebram decodificadores ingênuos. Os segmentos de um JWT são base64url sem padding (RFC 7515 §2), então um decodificador que exige padding com = rejeita a maioria dos tokens reais. O alfabeto usa - e _ em vez de + e /, então um decodificador Base64 padrão falha em cerca de metade de todos os tokens, dependendo do que os bytes aleatórios codificaram.
O que esta ferramenta acrescenta além da decodificação é a interpretação. As claims registradas do RFC 7519 vêm anotadas com o que significam. exp, nbf e iat são NumericDates — segundos desde o Unix epoch — então são exibidos como um timestamp real e um tempo relativo, porque “1757546000” não é algo com que você possa agir, e “expirou há 4 horas” é.
Depois, ele procura os problemas específicos que causam incidentes: um alg none, um segmento de assinatura vazio, um token sem exp, um token ainda não válido porque o relógio do emissor está adiantado, um aud ausente que permite o replay do token contra um serviço diferente que confie no mesmo emissor.
Ele deliberadamente para antes da verificação. Conferir uma assinatura exige o segredo ou a chave pública do emissor, e a única forma de uma página web obter uma é enviando o seu token a algum lugar. Oferecer isso destruiria a única propriedade que torna seguro colar uma credencial real nesta página.
Segmento do token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIiOiJ1c3JfOGYyYTFiIiwiZXhwIjoxNzU3NTQ2MDAwfQ .3Zc0Kz1qHhVQ9oFmR2sT7xYbN4dJwEuLpAiCgXvKmO8
Decodificado
header { "alg": "HS256", "typ": "JWT" }
payload { "sub": "usr_8f2a1b", "exp": 1757546000 }
exp 2026-09-10 21:53:20 UTC (expired)
sub Subject — who the token is aboutQuais opções e casos-limite o Decodificar JWT suporta?
| Parâmetro | Tipo | Padrão | Comportamento e casos-limite |
|---|---|---|---|
| alg | string | obrigatório | Algoritmo de assinatura, no cabeçalho. HS* é HMAC com um segredo compartilhado; RS*/PS* são RSA; ES* é ECDSA; EdDSA é Ed25519. Um valor de "none" é sinalizado como erro: uma biblioteca que confia em alg do próprio token permite que qualquer pessoa o forja. |
| typ / kid | string | opcional | typ é convencionalmente "JWT". kid identifica qual chave assinou o token e é o que permite a um emissor rotacionar chaves sem invalidar tudo de uma vez. |
| exp | NumericDate | opcional | Segundos desde a época Unix, não milissegundos e nem uma string ISO. Decodificado aqui para um timestamp UTC e um tempo relativo. Um token sem exp nunca expira por si só e só pode ser parado por revogação. |
| nbf | NumericDate | opcional | Não antes (Not-before). Um token que ainda não é válido é quase sempre um desvio de clock entre o servidor emissor e a máquina que o lê, e não uma deliberação. |
| aud | string | string[] | opcional | Destinatário pretendido. Um serviço deve rejeitar um token cujo público não é ele mesmo; sem aud, um token criado para um serviço pode ser reutilizado contra outro que confia no mesmo emissor. |
| Codificação do segmento | base64url | sem padding | RFC 7515 §2 usa o alfabeto seguro para URL (- e _) com padding removido. Decodificadores Base64 padrão falham em tokens cujos bytes produzem + ou /, é por que às vezes um token decodifica em uma ferramenta e não em outra. |
| Assinatura | base64url | não verificado | Exibida mas nunca verificada. A verificação requer a chave do emissor; obter uma significaria transmitir seu token. Um segmento de assinatura vazio é sinalizado, pois significa nenhuma proteção de integridade. |
| Tamanho da entrada | bytes | 8 MB | O limite do thread principal compartilhado em todo o site. Tokens reais têm alguns quilobytes; o limite existe para que colar o errado não trave a aba. |
Perguntas frequentes
É seguro colar um JWT real nesta página?
A decodificação acontece inteiramente no seu navegador e o token nunca é transmitido — abra o DevTools, vá ao painel Network, cole um token e você não verá nenhuma requisição carregando-o. Isso torna esta página categoricamente mais segura do que um decodificador que envia para um servidor, onde o seu token vai parar em um log de acesso. A ressalva restante não é sobre este site: qualquer credencial que você colar em qualquer navegador de uma máquina que você não controla deve ser rotacionada depois.
Por que ele não pode verificar a assinatura?
Porque a verificação precisa da chave. Para HS256, é o segredo compartilhado; para RS256, é a chave pública do emissor, geralmente obtida de um endpoint JWKS. Uma página web só poderia fazer um ou outro enviando o seu token, ou o segredo, a algum lugar — o que destruiria a propriedade que torna esta página segura de usar. A verificação pertence ao seu serviço, onde a chave já está.
Meu token decodifica aqui, mas a minha biblioteca o rejeita. Por quê?
Decodificar e aceitar são questões diferentes. As causas mais comuns são: o token expirou (confira a linha do exp — esta ferramenta o mostra como uma data real); a audiência não corresponde ao que o seu serviço espera; o nbf está no futuro porque o relógio do servidor emissor está adiantado; ou a assinatura não confere com a chave com que o seu serviço está configurado, geralmente porque o emissor rotacionou as chaves e o kid agora se refere a uma que o seu cache ainda não buscou.
O que significa alg: none e por que ele é sinalizado como erro?
Significa que o token não tem assinatura. O perigo não é o valor em si, mas o que um verificador faz com ele: algumas bibliotecas de JWT historicamente liam o alg do token e escolhiam o método de verificação de acordo, então um atacante podia pegar um token válido, mudar o algoritmo para none, remover a assinatura e vê-lo aceito. Um verificador correto decide o algoritmo esperado a partir da sua própria configuração e ignora o que o token alega.
Um JWT é criptografado?
Não. Um JWT padrão (um JWS) é assinado, não criptografado — a assinatura prova que o payload não foi alterado, e não faz nada para escondê-lo. Toda claim é legível por qualquer pessoa que tenha o token, que é exatamente o que esta página demonstra. Se você precisa esconder o conteúdo, o que você quer é um JWE, que tem cinco segmentos em vez de três e não pode ser lido sem a chave de descriptografia.
Dá para decodificar um token que já expirou?
Sim. A expiração é uma claim dentro do payload, não uma propriedade da codificação, então um token expirado decodifica exatamente como um válido. Esta ferramenta o lê e diz quando ele expirou e há quanto tempo, o que costuma ser a forma mais rápida de confirmar que um 401 intermitente é um problema de tempo de vida do token, e não de permissões.