Como decodificar um JWT

Cole o token em um decodificador que roda no seu navegador, nunca em um que peça envio; leia o header e o payload, confira exp contra o horário atual e trate alg:none como um alarme. Decodificar é ler, não verificar — só a chave do emissor prova que um token é genuíno. Cada etapa abaixo acontece localmente no decodificador de JWT do site.

Só local

Só quer a ferramenta? Abra Decodificar JWTDecifra o token e explica o que cada claim significaAbrir ferramenta

Um JSON Web Token parece papel de parede — três segmentos base64 unidos por pontos — e esse disfarce é exatamente o motivo de valer a pena um procedimento para decodificá-lo de forma deliberada, em vez de ficar encarando o bicho tentando decifrá-lo. Dentro dele há um header que nomeia o algoritmo de assinatura, um payload que diz de quem o token é e quando ele morre, e uma assinatura que (se for genuína) liga ambos a quem o emitiu. Os dois primeiros podem ser lidos por qualquer um; o terceiro só pode ser conferido com uma chave.

Esta página é a versão segura desse trabalho de leitura: cinco etapas, cada uma com uma verificação, todas executadas no seu próprio navegador. A distinção importa porque um JWT é uma credencial bearer — quem o detém pode usá-lo. Colar um token em uso numa página qualquer que o decodifica no servidor é entregar essa credencial ao dono da página; colá-la numa ferramenta que decodifica localmente não a entrega a ninguém, e o painel Network é como você verifica essa afirmação em vez de confiar nela.

Uma expectativa a ajustar antes da primeira etapa: um decodificador pode dizer o que um token diz e sinalizar o que parece errado, mas não pode dizer que um token é genuíno. Autenticidade é uma questão de assinatura, e questões de assinatura precisam da chave do emissor. A última etapa é sobre onde essa verificação realmente acontece — e por que a resposta normalmente não é esta página.

Todas as cinco etapas rodam no decodificador de JWT — cole, leia, e cada claim chega com o significado anexado.

Para a anatomia completa dos três segmentos, o guia de estrutura de JWT explica cada parte com exemplos concretos antes de você inspecionar um token real.

Os passos

Copie apenas o token — nada antes nem depois
Do cabeçalho da resposta, da entrada no localStorage ou da requisição que você está inspecionando, copie exatamente os três segmentos base64: o trecho que começa em eyJ e termina no último caractere do terceiro segmento separado por pontos. Remova qualquer prefixo Bearer, aspas e espaços em branco — um decodificador tolera um pouco disso, mas colar um token limpo torna cada verificação seguinte inequívoca.
Verifique: O que você copiou começa com eyJ (o base64 de {" — todo header de JWT começa assim) e não contém espaços. Essa verificação minúscula pega a falha de colagem mais comum antes de qualquer ferramenta entrar em cena.
Cole em um decodificador que roda localmente
Abra o decodificador de JWT e cole. O header e o payload são decodificados instantaneamente, na aba — nada é enviado, e o painel Network não mostrará nenhuma requisição carregando o token. É aqui que as versões segura e insegura deste procedimento se separam: um decodificador no servidor viu seu token; um local não viu, porque o token nunca sai da sua máquina.
Verifique: Dois objetos JSON aparecem — o header primeiro, o payload abaixo — sem nenhum erro entre eles. Se o decodificador reporta base64 inválido ou JSON quebrado, o token foi truncado ou corrompido na cópia; copie de novo a partir da origem.
Leia o header — o algoritmo define o modelo de ameaças
O alg do header nomeia como o token foi assinado: HS256 significa um segredo compartilhado, RS256 ou ES256 significa um par de chaves em que só o emissor detém a metade privada, none significa sem assinatura. A ferramenta sinaliza alg:none em voz alta, porque um token sem assinatura é uma afirmação que qualquer um poderia ter escrito — aceitar um não é um engano, é uma falha de política. Anote o alg agora; a etapa cinco vai precisar dele.
Verifique: A linha do alg mostra um algoritmo real (HS256, RS256, ES256 são os três mais comuns) e nunca none. Se mostrar none, pare: o token não prova nada sobre si mesmo, e quem o emitiu precisa ficar sabendo.
Leia o payload — e confira exp contra o horário real
As claims do payload são toda a história do token: sub diz de quem ele é, iss diz quem o criou, aud diz quem pode aceitá-lo, e exp é o momento em que ele morre — decodificado numa data e hora reais pela ferramenta, e não o 1735689600 que você teria de converter por conta própria. A ferramenta também emite avisos: um token expirado, um sem exp nenhuma, um cujo nbf está no futuro porque o relógio do emissor está adiantado.
Verifique: A linha do exp mostra uma data com que dá para raciocinar — "expirou há 4 horas" ou "expira em 11 minutos" — e a lista de avisos corresponde ao que você vê. Um token sem exp merece desconfiança: no papel, ele nunca expira.
Verifique com o emissor — não com o decodificador
Decodificar não prova nada sobre autenticidade: o segmento de assinatura só pode ser conferido contra uma chave, e a chave pertence ao emissor. Na prática, a verificação acontece onde a chave vive — seu backend, um API gateway, a biblioteca do seu provedor de identidade — não numa aba do navegador. Se você está depurando por que um serviço rejeitou um token, leve as claims decodificadas a esse serviço: um exp que já passou, um aud que não bate ou um kid que o cache de chaves ainda não pegou explicam a maioria das rejeições.
Verifique: Você consegue dizer, para o token diante de você, quem deve verificá-lo (o serviço que o aceitou) e o que esse serviço confere (a assinatura contra a chave do emissor, mais exp, nbf e aud). Se não consegue, o guia de estrutura de JWT tem a peça que falta.

Decodificar e verificar são verbos diferentes

Decodificar é parse de base64 e JSON — leitura. Verificar é uma operação criptográfica — conferir a assinatura contra uma chave que só o emissor tem. Um decodificador que mostrasse um selo verde de "válido" estaria mentindo, porque nunca terá a chave privada do emissor, e mesmo com algoritmos de chave pública a verificação pertence ao serviço que aceita o token, que sabe qual chave e qual audience se aplicam.

É por isso que a ferramenta nunca afirma validade e em vez disso explica o que vê: o algoritmo, as claims, a expiração como uma data e os avisos que um leitor atento faria. O leitor que precisa de um veredito — a API que recebe o token — é a única parte com os materiais para dá-lo.

As claims que você deve ler sempre

Quatro claims registradas carregam a maior parte da história. exp: quando o token morre — a linha mais útil da página. sub: sobre quem o token é, geralmente um identificador de usuário ou de serviço. iss e aud: quem o emitiu e quem pode aceitá-lo — um token emitido para uma API costuma ser rejeitado por outra, e o lado que rejeita não está com defeito: está lendo aud corretamente.

Claims personalizadas (roles, scopes, tenant ids) ficam ao lado e são decodificadas da mesma forma, mas trate-as como claims, não como fatos: são tão confiáveis quanto a assinatura por trás delas, que o decodificador não conferiu. iat (issued at) e nbf (not before) completam as claims da linha do tempo e explicam a classe de erros do tipo "token ainda não válido", que quase sempre é dessincronização de relógio.

O que um decodificador pode sinalizar — e o que só o servidor pode saber

A camada de avisos captura o que o payload admite à primeira vista: alg:none, um segmento de assinatura vazio, um exp no passado, um token sem exp nenhuma, um nbf no futuro. Esses são os defeitos visíveis sem nenhuma chave, e vale lê-los mesmo quando o token "funciona" — um sistema que aceita um token expirado é um sistema sobre o qual você quer saber.

O que nenhuma ferramenta de navegador pode dizer: se a assinatura realmente verifica, se o emissor ainda reconhece esta sessão, se o token foi revogado. Essas respostas ficam atrás da chave do emissor e dos registros dele. A honestidade do decodificador é a fronteira que ele traça entre ler um token e confiar em um.

Onde os tokens se escondem — e por que isso pede decodificação local

JWTs moram em cabeçalhos Authorization, no localStorage do navegador, em fragmentos de URL após redirecionamentos de login e em logs de aplicação — lugares copiados com muito mais descuido do que arquivos. Cada uma dessas cópias é uma credencial em uso até expirar, e é por isso que a etapa de decodificação deste procedimento insiste numa ferramenta local: capturas de tela, tickets e mensagens de chat contendo payloads decodificados podem ser lidos por qualquer um, mas o token em si não deve viajar para lugar nenhum, exceto para os serviços que existem para verificá-lo.

Os hábitos práticos decorrem disso: decodifique localmente, oculte dados antes de compartilhar (o payload numa captura de tela costuma bastar para depurar) e, quando um token precisar circular para depuração, faça-o pelo canal que o emissor consideraria aceitável — não num site público de paste.

Perguntas frequentes

É seguro colar meu JWT neste decodificador?

Sim, porque a decodificação acontece no seu navegador — o token é processado por código local e nunca transmitido a lugar nenhum. Você não precisa aceitar isso na fé: abra o DevTools, abra o painel Network, cole um token e observe que nenhuma requisição o carrega. A Content-Security-Policy do site proíbe conexões de saída por construção, então nem um bug poderia exfiltrá-lo.

Decodificar me diz se um token é válido?

Não, e um decodificador que afirmar isso está te enganando. Validade é uma questão de assinatura — o token precisa ser conferido contra a chave do emissor, mais as políticas de exp, nbf e aud do serviço que o recebe. Um decodificador mostra o que o token diz e sinaliza defeitos de superfície (expirado, sem assinatura, exp ausente); o veredito pertence ao verificador que detém a chave.

O que significa alg:none e por que ele é perigoso?

Significa que o header declara nenhum algoritmo de assinatura — o segmento de assinatura deve estar vazio, e o conteúdo do token é uma afirmação que qualquer um poderia ter escrito. Algoritmos como HS256 existem justamente para que a adulteração seja detectável; alg:none remove essa garantia. Um decodificador o sinaliza em voz alta porque aceitar esse tipo de token é uma classe de vulnerabilidade conhecida, não uma peculiaridade de formatação.

Por que meu token aparece como expirado se o app continua funcionando?

Porque o app o renovou. Access tokens de vida curta expiram de propósito e são trocados por novos nos bastidores, normalmente com um refresh token; o que você copiou provavelmente já era uma geração aposentada. Decodifique o token que o app está enviando agora e o exp dele deve estar no futuro — se não estiver, o serviço que o aceita não está conferindo a expiração, e isso vale saber.

Em que unidade exp, iat e nbf são medidos?

Segundos desde 1º de janeiro de 1970 em UTC — o Unix time — e é por isso que um payload cru os mostra como números de dez dígitos, como 1735689600. O decodificador converte cada um numa data e hora reais e expressa a relação com o agora ("expirou há 4 horas", "expira em 11 minutos"), que é a forma com que uma pessoa realmente consegue agir.

Posso compartilhar uma captura de tela de um token decodificado?

O header e o payload decodificados costumam estar bem — são legíveis por design, e uma captura de tela mostrando claims é como a maior parte da depuração acontece. O que nunca deve ser compartilhado é o token em si: ele é uma credencial bearer, e quem o detém pode usá-lo até expirar. Oculte os segmentos de assinatura e qualquer identificador que você não colocaria num ticket, e mantenha o token completo totalmente fora das capturas de tela.

Equipe ToolsByUs · Como verificamos nossas ferramentas