Decodificador de JWT

O que é um JWT?#

Um JWT (JSON Web Token, definido na RFC 7519) é um token compacto, seguro para URL, construído para transportar claims entre duas partes. É a credencial que o seu navegador envia para uma API após o login, a asserção de identidade que um provedor OAuth entrega a uma aplicação que depende dela, e o envelope em que a maioria dos fluxos modernos de sessão e controlo de acesso viaja. O apelo é que as claims — quem é o usuário, o que pode fazer, quando expira o token — viajam dentro do próprio token como JSON, pelo que o serviço receptor as consegue ler sem ir procurar na base de dados.

Um JWT tem exatamente três partes codificadas em base64url separadas por pontos: header.payload.signature. O header indica o algoritmo e o tipo de token. O payload é um objeto JSON de claims — as registradas como sub (sujeito), iat (emitido em), exp (expiração), nbf (não antes de), mais quaisquer claims personalizadas que a aplicação adicione. A signature é o que o emitente calculou sobre as outras duas partes com um segredo ou chave privada; verificá-la é o que prova que o token não foi adulterado.

Esta página decodifica e inspeciona um JWT. Divide as três partes, decodifica por base64url o header e o payload em JSON legível, eleva as claims de tempo padrão a carimbos legíveis por humanos, e mostra um emblema de estado ao vivo (Válido, Expirado, Ainda não válido). Propositadamente não verifica a assinatura — isso exige o segredo ou a chave pública do emitente e está fora do âmbito de uma ferramenta 100% do lado do cliente. O segmento de assinatura é mostrado em bruto, exatamente como recebido.

Como usar#

1. Cole o seu token na caixa de entrada à esquerda. Tem de ser três segmentos separados por pontos; o espaço ao redor é aparado automaticamente.
2. Clique em Exemplo para carregar um token de exemplo interno (com iat/exp/nbf) se só quer ver como a disposição funciona.
3. Clique em Limpar para esvaziar a entrada e os painéis de resultado.
4. Leia o painel direito:
   • O emblema de estado no topo — Válido verde, Expirado, ou Ainda não válido — com base nas claims nbf e exp comparadas com a hora atual.
   • O cartão Header (com o algoritmo mostrado na sua barra de título, por exemplo HS256).
   • O cartão Payload, impresso de forma bonita como JSON.
   • A lista de claims de tempo — Emitido em, Não antes de, Expira — cada um renderizado tanto como carimbo unix como data legível.
   • O segmento de Assinatura, mostrado em bruto porque ainda são bytes codificados em base64url.
5. Se o token está mal formado, a linha de estado vermelha diz-lhe se falhou a verificação de forma de três segmentos, a decodificação base64url, ou a análise JSON.

Principais recursos#

• Estado ao vivo das claims de tempo. Lê iat, nbf e exp e diz-lhe se o token é atualmente válido, já expirou, ou ainda não entrou em vigor — as três perguntas que se fazem durante um bug de login.
• Datas legíveis por humanos. Números de época unix como 1700000000 são mostrados ao lado da data UTC que representam, para que se pare de fazer aritmética mental de época.
• Algoritmo elevado. O valor alg do header é puxado para a barra de título do cartão Header, para que se veja imediatamente se tem um HS256, um RS256 ou algo inesperado.
• Descodificação segura a UTF-8. Segmentos base64url são decodificados como bytes através de TextDecoder, pelo que claims não-ASCII (nomes, roles noutras escritas) renderizam corretamente em vez de mojibake.
• Só decodifica — nunca verifica. A ferramenta nunca pede um segredo, o que a torna segura para colar tokens em que não confia totalmente: nada é enviado para lado nenhum, e a assinatura é mostrada mas não verificada.

Exemplo detalhado#

Clique em Exemplo e a entrada preenche-se com um token cujo header decodifica para:

{
  "alg": "HS256",
  "typ": "JWT"
}

e cujo payload decodifica para:

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

A lista de claims de tempo mostra então:

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

O emblema de estado lê Válido, porque a hora atual é depois de nbf e antes de exp. O segmento de assinatura é mostrado como a string literal c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ — que decodifica para o texto “sample-signature-not-verified”, um marcador deliberado de que a assinatura deste token é ilustrativa, não um output real de HMAC-SHA256.

Esse último ponto é a coisa mais importante a perceber sobre esta ferramenta: um token que decodifica de forma limpa não é necessariamente um token de confiança. Qualquer pessoa pode forjar o header e o payload; só a assinatura, verificada contra o segredo ou chave pública do emitente, prova autenticidade. Use esta página para ler claims e depurar janelas de tempo; verifique assinaturas no seu backend real.

Perguntas frequentes#

Esta ferramenta consegue dizer-me se um JWT é autêntico?#

Não, e isso é por desenho. Descodificar só lê o JSON dentro do token — não prova que o token foi emitido por quem afirma tê-lo emitido. Para verificar autenticidade precisa da chave apropriada ao alg (um segredo compartilhado para HS256, a chave pública do emitente para RS256/ES256) e uma rotina de verificação num backend de confiança. Nunca trate um token decodificado de forma limpa como um token verificado.

O estado diz “Expirado”. Posso renovar o token aqui?#

Não. Renovar significa chamar o endpoint de refresh do seu servidor de autenticação para obter um novo token de acesso — uma operação de rede que esta página estática e do lado do cliente não consegue nem deve executar. O que pode fazer aqui é confirmar exatamente quando o token antigo expirou, que é normalmente a pista de que precisava.

Qual é a diferença entre iat, nbf e exp?#

iat (issued at) é quando o token foi criado — informativo. nbf (not before) é a hora mais cedo a que o token deve ser aceite; antes de nbf um servidor validador deve rejeitá-lo mesmo que a assinatura seja válida. exp (expiração) é o corte duro após o qual o token tem de ser rejeitado. Um token bem formado tem nbf ≤ iat ≈ agora e exp algures no futuro próximo (minutos para tokens de acesso, mais para refresh tokens).

O meu payload contém carateres não-ASCII e noutros lados aparecem corrompidos. Porque estão aqui certos?#

Porque alguns decodificadores tratam erroneamente cada caráter base64url como um byte em vez de decodificar para bytes em bruto primeiro. Esta página decodifica para um Uint8Array e depois passa-o por TextDecoder, que interpreta os bytes como UTF-8 próprio. Essa é a forma correta, e é por isso que nomes, roles e scopes em qualquer escrita aparecem como foram escritos.