Decodificador de Token JWT

JWT (JSON Web Token) é um padrão aberto (RFC 7519) para transmitir informações de forma compacta e verificável entre partes como um objeto JSON. É composto por três partes separadas por pontos: Header (cabeçalho com algoritmo e tipo), Payload (dados/claims) e Signature (assinatura). É amplamente usado para autenticação e autorização em APIs.

Cole o token inteiro no campo "Token JWT" e clique em "Decodificar JWT". A página separa os três trechos pelos pontos, converte o cabeçalho e o payload de Base64URL para JSON e mostra o algoritmo, o tipo, as datas e o payload completo. Para fazer à mão, pegue o trecho do meio, troque - por + e _ por /, complete com = até o tamanho ser múltiplo de 4 e decodifique como Base64 comum. Sai o mesmo JSON, porque nenhuma chave entra nessa conta.

Olhe o campo exp do payload. Ele marca, em segundos desde 1º de janeiro de 1970 (UTC), o instante a partir do qual o token deve ser recusado; se o relógio já passou desse número, o token venceu. Esta página faz a conta com o relógio do seu computador, mostra a data no horário de Brasília e confere também o nbf, que marca quando o token começa a valer. Quem decide de verdade é o servidor: ele pode aceitar uma pequena folga para relógio desacertado (a RFC 7519 fala em poucos minutos, no máximo) e pode recusar um token revogado antes do exp.

Não. Esta ferramenta apenas decodifica o header e o payload do JWT, não valida a assinatura. Para validar a assinatura, seria necessário ter a chave secreta (para HMAC) ou a chave pública (para RSA/ECDSA) usada pelo servidor emissor. Nunca confie em um JWT apenas porque ele pode ser decodificado, sempre valide a assinatura no servidor.

O processamento é 100% local no navegador, nenhum token é enviado para servidores. Porém, recomendamos evitar colar tokens de produção ativos, especialmente tokens com dados sensíveis, credenciais ativas ou tokens de longa duração. Prefira testar com tokens de desenvolvimento ou tokens já expirados. Um token de acesso dentro do prazo vale como credencial até o exp: quem tiver uma cópia dele faz pedidos em nome do usuário sem saber a senha.

São claims de tempo padronizadas pelo RFC 7519: exp (Expiration Time) define quando o token expira e não deve mais ser aceito; iat (Issued At) indica quando o token foi emitido; nbf (Not Before) indica a partir de quando o token pode ser usado. Todos são representados como NumericDate, ou seja, segundos desde 1970-01-01T00:00:00Z. Um token com nbf no futuro ainda não vale, mesmo que o exp esteja longe: a página trata esse caso como token que ainda não entrou em vigor, e não como token dentro do prazo.

Porque o valor foi gravado em milissegundos, e o RFC 7519 exige segundos. É o erro clássico de usar Date.now() em JavaScript sem dividir por 1000. Um exp de 13/09/2026 gravado assim vira 1.789.322.083.000, e esse número lido como segundos cai no ano 58671. O defeito é de quem emitiu o token, e não da sua leitura. Quando o valor chega a 100.000.000.000, que em segundos já seria o ano 5138, esta página avisa que o campo provavelmente está em milissegundos, mostra a data na leitura correta e não conclui nada sobre o prazo com esse campo.

Não, e confundir as duas coisas é uma das causas mais comuns de falha de autorização. Decodificar é desfazer o Base64URL, que é codificação e não criptografia: qualquer pessoa com o token consegue ler o payload, inclusive quem inventou o conteúdo. Validar é recalcular a assinatura com a chave do emissor e conferir se bate, e isso só o servidor que tem a chave consegue fazer. Esta página só decodifica. Quando ela diz que as datas estão dentro do prazo, isso significa apenas que exp e nbf estão coerentes com o relógio, sem nenhuma afirmação sobre autenticidade.

Os principais são: HS256/HS384/HS512 (HMAC com SHA-2, chave simétrica compartilhada), RS256/RS384/RS512 (RSA com SHA-2, par de chaves pública/privada), ES256/ES384/ES512 (ECDSA, criptografia de curva elíptica) e PS256/PS384/PS512 (RSA-PSS). O algoritmo 'none' não usa assinatura e deve ser rejeitado por servidores em produção. Todos esses nomes estão registrados na RFC 7518, a especificação dos algoritmos do JWT, que também define o none.

São os dois campos que a página mostra no quadro "Cabeçalho (Header)". O alg diz qual algoritmo assinou o token: HS256 é HMAC com SHA-256 e uma chave compartilhada, RS256 é RSA com SHA-256 e um par de chaves, ES256 usa curva elíptica. O typ costuma valer JWT e só declara o tipo do objeto. Quando o alg vem como none, o token não tem assinatura nenhuma, e um servidor bem configurado recusa esse token. Se o campo não existir, a página escreve "não informado".

É a faixa cinza que aparece quando o token traz exp ou nbf, mas o valor não serve para a conta. Acontece com data escrita como texto, com número negativo e com data em milissegundos, que aparece como um valor de 100.000.000.000 para cima. Em vez de pintar de verde um token com data no ano 58671, a página explica o defeito na caixa "Problemas nos campos de data deste token" e deixa o prazo em aberto. A correção é no serviço que emite o token, gravando o valor em segundos.

Base64URL é uma variante do Base64 que substitui '+' por '-' e '/' por '_', e omite o padding '='. Essa variante é necessária porque '+', '/' e '=' têm significados especiais em URLs e parâmetros de query string. O JWT usa Base64URL para codificar o header e o payload, tornando o token seguro para uso em URLs.