Decodificador de JWT
Cole um JSON Web Token para ver o que realmente há dentro dele — o header e o payload, decodificados e formatados para leitura.
Entendendo as claims lá dentro
Depois que um token é decodificado, o payload é, na maior parte, um punhado de campos curtos e padronizados chamados claims. Os que você vai encontrar o tempo todo: iss nomeia o emissor que criou o token, sub identifica o usuário ou o assunto a que ele se refere, aud nomeia a audiência — a API para a qual ele se destina —, enquanto iat registra quando foi emitido e exp quando deixa de ser válido. Qualquer outra coisa ali é personalizada: papéis, endereços de e-mail, feature flags, o que quer que o sistema emissor decida incluir. As claims de tempo confundem as pessoas porque são timestamps Unix simples, segundos desde 1970 — um número como 1784528768, em vez de uma data legível — então a vida útil inteira do token se esconde em dois inteiros discretos.
Depurando um token rejeitado
Quando uma API responde 401 e você tem certeza de que o token está certo, percorra uma lista curta. Primeiro, se você o copiou de um cabeçalho Authorization, remova a palavra Bearer e o espaço na frente — com eles ainda ali, não é um JWT válido e nem vai decodificar. Em seguida, leia o exp e verifique se ele realmente está no futuro: cole o número no conversor de timestamp Unix e você verá a expiração como uma data real, muitas vezes revelando um token que morreu horas atrás. Depois compare aud e iss com a API que você está chamando — um token cunhado para o ambiente de staging é rotineira, e corretamente, recusado em produção. E lembre-se de que um minuto de diferença de relógio entre servidores já é o suficiente para fazer um token recém-emitido parecer ainda-não-válido.
Tokens que esta ferramenta não consegue abrir
Nem tudo que protege uma API é um JWT legível. Um token com cinco partes separadas por ponto, em vez de três, é um JWE — genuinamente criptografado, não apenas codificado — e nada legível sai dele sem a chave, aqui ou em qualquer outro lugar. E muitos tokens de sessão são simplesmente strings aleatórias opacas que nunca foram JWTs para começo de conversa; se não começar com algo como eyJ, provavelmente não há nada para decodificar. Para os tokens que abrem, ajuda lembrar o que você está vendo: três blocos de texto em Base64URL colados com pontos. A ferramenta de Base64 decodifica qualquer bloco isolado sozinho, o que é uma boa forma de ver com os próprios olhos que as partes legíveis de um JWT nunca foram secretas, para começar.
O que decodificar um JWT revela — e o que não revela
O header e o payload de um JWT são apenas JSON codificado em Base64URL — qualquer pessoa pode decodificá-los e lê-los, sem precisar de nenhum segredo, e é exatamente isso que esta ferramenta faz. O que ela não consegue fazer é verificar a assinatura: isso exige o segredo ou a chave pública do emissor, que propositalmente não é algo que você colaria em um site qualquer.
Isso verifica se o token é válido ou se ainda não expirou?
Não — isso apenas decodifica as partes legíveis. A verificação da assinatura e a checagem da expiração ("exp") acontecem no servidor que emitiu o token, usando um segredo que esta ferramenta nunca vê.
Um JWT deveria mesmo ser legível assim?
Sim — o header e o payload são apenas codificados, não criptografados. Nunca coloque segredos ou dados sensíveis diretamente no payload de um JWT; a assinatura serve para provar que ele não foi alterado, não para esconder o seu conteúdo.
Meu token é enviado para algum lugar?
Não — a decodificação acontece inteiramente no seu navegador, com JavaScript puro. Nada é enviado.
