Decodificar JWT — Ler Cabeçalho e Payload
Decodifique um JWT para ler claramente seu cabeçalho e payload, na hora e com privacidade.
O token fica no seu aparelho
Nada para apagar depois
Feito para credenciais vivas
Funciona em todo navegador moderno
Como funciona
- 1
Cole o token
Inteiro, com os dois pontos: as três partes são separadas por eles.
- 2
Leia os claims
Cabeçalho de um lado, payload do outro, com marcações de tempo convertidas em datas.
- 3
Confira o que você veio ver
Normalmente a expiração, o emissor, a audiência ou de qual usuário o token realmente é.
Por que usar esta ferramenta
Cabeçalho e payload lado a lado
O algoritmo e a dica de chave junto dos claims, que é onde a maioria das dúvidas de depuração se resolve.
Marcações de tempo legíveis
`exp`, `iat` e `nbf` mostrados como datas em vez de números de dez dígitos que você teria de converter.
Expiração comparada ao agora
Você vê na hora se o token ainda está dentro da janela, sem fazer a conta.
Honesto sobre verificação
Isto decodifica; não verifica assinatura, e diz isso em vez de sugerir que o token é válido.
Nada é transmitido
O token é analisado no seu navegador — uma credencial de sessão em uso nunca chega a um servidor.
Grátis e sem conta
Sem cadastro, sem marca d’água e sem limite de quantos tokens você inspeciona.
Decodificar não é verificar, e a diferença é o modelo de segurança inteiro
Um JWT tem três partes separadas por pontos, e as duas primeiras são simplesmente texto base64url. Qualquer um que tenha o token consegue ler o cabeçalho e o payload num passo — é o que esta página faz — e isso não exige chave, permissão nem segredo. Verificar é uma operação completamente separada: recalcular a assinatura sobre as duas primeiras partes com a chave do emissor e checar se bate com a terceira. Só a verificação diz que o token é autêntico e não foi modificado. Um decodificador diz o que um token afirma, nunca se a afirmação é verdadeira, porque qualquer um pode forjar um token dizendo o que quiser. Se você está depurando, decodificar responde à sua pergunta. Se está decidindo se confia numa requisição, decodificar não responde absolutamente nada.
O payload é legível por qualquer um, e as pessoas esquecem isso o tempo todo
Isso decorre do anterior e merece ser dito à parte, porque é fonte de exposição real de dados. O payload de um JWT é codificado, não criptografado. Cada claim nele — o identificador de usuário, o e-mail, o papel, o tenant, quaisquer campos internos que pareceram convenientes de incluir — é visível para quem tiver o token, inclusive o navegador para o qual foi emitido, qualquer extensão rodando nesse navegador e qualquer um que o obtenha depois. A assinatura protege o payload de ser alterado, não de ser lido. Então um token é um lugar razoável para um identificador e um papel, e um lugar ruim para um endereço, um telefone, um status de licença que alguém possa achar constrangedor ou qualquer coisa que você não imprimiria do lado de fora de um envelope. Se um claim precisa ficar privado, ele não pertence ao token.
Nunca deixe o token te dizer como verificá-lo
As vulnerabilidades de JWT mais famosas compartilham um mesmo formato: uma biblioteca lê o campo `alg` do cabeçalho e confia nele. A versão histórica é `alg: none`, que declara o token sem assinatura — um verificador que a honre aceita qualquer coisa, e o atacante simplesmente escreve o próprio payload e tira a assinatura. A versão mais sutil é a confusão de algoritmos: um token assinado com HMAC é apresentado a um servidor que espera RSA, e se o código passa a chave pública RSA como segredo HMAC, e essa chave pública é publicada, o atacante pode assinar tokens com ela. Ambas se corrigem do mesmo jeito: o código que verifica decide qual algoritmo e qual chave aceita e rejeita todo o resto, em vez de ler a resposta na parte não confiável do token que está checando.
As marcações de tempo são em segundos, e nada as impõe sozinho
Três claims controlam a janela em que um token é válido. `exp` é a expiração, `nbf` é o momento antes do qual ele não deve ser aceito e `iat` é quando foi emitido. Os três são segundos desde a época Unix, o que derruba quem trabalha numa linguagem cujas marcações nativas são milissegundos — o token resultante ou já está expirado ou vale pelos próximos cinquenta mil anos, e os dois erros são comuns o bastante para checar primeiro. O ponto mais importante é que esses são claims, não imposição. Nada no token para de funcionar quando `exp` passa; a expiração só existe se o código verificador a comparar com o horário atual e rejeitar a requisição. Um decodificador que te mostra um token expirado diz o que o emissor pretendia, não o que um servidor específico vai fazer com ele.
Um JWT não pode ser revogado, e esse é o acordo que você aceitou
A razão de usar esses tokens é a verificação sem estado: um servidor consegue confirmar que uma requisição é autêntica usando só uma chave, sem consultar banco, e é isso que os faz escalar entre serviços. A consequência direta é que não há nada para apagar. Uma sessão guardada no banco acaba no instante em que você remove a linha; um token assinado continua válido até expirar, não importa o que aconteça no emissor, porque nada consulta o emissor. Um token vazado é portanto utilizável até expirar, e é exatamente por isso que tokens de acesso devem ter vida curta — minutos, não semanas — com um token de refresh mais longevo que pode ser revogado porque ele *é* conferido contra armazenamento. Se os seus tokens de acesso duram um mês, você tem todas as desvantagens da ausência de estado e nenhuma segurança de sessão.
Por que este é o caso mais afiado para decodificar localmente
Quase toda outra ferramenta de texto lida com material sensível por circunstância. Um JWT é sensível por definição: ele é a credencial, e um token válido e não expirado basta para agir como o usuário para quem foi emitido. Colar um num decodificador hospedado envia uma credencial de autenticação em funcionamento a um terceiro, por um canal que não deixa rastro, em troca de ler campos que você poderia ter lido localmente. Se ainda faltam horas no token, quem o receber pode usá-lo. Esta página analisa no navegador e não transmite nada, o que você confere na aba Rede das ferramentas de desenvolvedor — e se você já colou um token de produção num site para ver a expiração, tratar esse token como comprometido é a resposta correta.
Erros comuns que vale evitar
- Tomar uma decodificação bem-sucedida por token válido. Decodificar não precisa de chave e não prova nada; só verificar a assinatura com a chave do emissor estabelece que o token é autêntico.
- Pôr dado privado no payload. Ele é codificado, não criptografado — a assinatura impede alteração, não leitura, então qualquer um com o token vê todos os claims.
- Deixar o token escolher o algoritmo de verificação. Ler `alg` do cabeçalho é como funcionam os ataques `alg: none` e de confusão de algoritmos; o verificador precisa fixar algoritmo e chave de antemão.
- Escrever `exp` em milissegundos. Marcações de JWT são segundos desde a época, então um valor em milissegundos gera um token válido por dezenas de milhares de anos — ou um já expirado.
- Colar um token de produção num decodificador hospedado. É uma credencial viva, a colagem não deixa rastro, e quem o receber pode usá-lo até expirar.
Comparação
| Item | Esta ferramenta | Decodificadores online | Uma chamada de biblioteca |
|---|---|---|---|
| Token enviado a um servidor | Nunca | Geralmente sim | Não |
| Marcações mostradas como datas | Sim | Às vezes | Você formata |
| Deixa claro que não verifica | Sim | Muitas vezes obscuro | Explícito na API |
| Funciona sem abrir um projeto | Sim | Sim | Não |
| Conta ou cadastro | Não precisa | Frequentemente exigido | Não precisa |
| Preço | Grátis | Grátis / planos pagos | Grátis |
Recursos
Análise completa das três partes
Cabeçalho, payload e segmento de assinatura mostrados separadamente como o formato define.
base64url tratado direito
JWTs usam o alfabeto seguro para URL sem preenchimento, algo que um decodificador Base64 comum erra.
Claims padrão rotulados
`iss`, `sub`, `aud`, `exp`, `nbf`, `iat` e `jti` são nomeados em vez de ficarem como abreviações.
Tokens malformados sinalizados
Um segmento ausente ou codificação inválida é reportado em vez de gerar besteira parcial.
Unicode nos claims preservado
Nomes e valores em árabe, turco ou qualquer escrita decodificam intactos.
Instantâneo, sem requisição
A análise acontece ao colar, sem nada ser buscado e sem nada ser enviado.
Nada para instalar
Sem biblioteca, sem runtime, sem dependências — funciona na página web.
Compatível com árabe e RTL
Interface completa em oito idiomas, incluindo árabe da direita para a esquerda.
Seguro por padrão
Servido por HTTPS, sem rastreio de conteúdo e sem envio a terceiros.
Quem usa
Desenvolvedores
Ver por que uma chamada de API é recusada — quase sempre um token expirado ou a audiência errada.
Engenheiros de segurança
Inspecionar os claims e o algoritmo de um token achado num log ou num relato de bug.
Integradores de API
Confirmar quais escopos e papéis um provedor de fato emitiu antes de escrever código contra eles.
Engenheiros de suporte
Ler um token enviado pelo cliente para ver a qual conta e tenant ele pertence.
Perguntas Frequentes
Não. Tudo roda localmente no seu navegador — seu texto nunca é enviado, armazenado ou compartilhado.
Sim — totalmente grátis, sem conta e sem limites.