Toolivaro

Decodificador de JWT grátis

Decodifique o header, o payload e os claims de um JWT localmente — com verificação opcional de assinatura HMAC. Nada sai do seu navegador.

O decodificador de JWT lê os JSON Web Tokens que suas APIs emitem e consomem — a forma compacta header.payload.signature usada por OAuth 2.0, OpenID Connect e inúmeras bibliotecas de autenticação — e os exibe como JSON legível e formatado: o header com seu algoritmo e id de chave, o payload com seus claims, e o segmento de assinatura bruto. A decodificação acontece inteiramente no seu navegador: a decodificação base64url e o parsing JSON são locais, então a ferramenta é segura até com tokens de produção que carregam identificadores reais de usuário, e-mails e detalhes de sessão — nada é enviado, registrado ou armazenado. O que este decodificador não fará é exagerar. Ele pode verificar uma assinatura HMAC quando você cola o segredo: a ferramenta calcula o HMAC com WebCrypto e informa Assinatura válida ou Assinatura inválida, para você confirmar que um token foi de fato assinado com o segredo que você tem e não foi adulterado no trânsito. Essa verificação é honesta sobre seu alcance: apenas HS256, HS384 e HS512 podem ser verificados com um segredo compartilhado no navegador. Tokens assimétricos — RS256, ES256, PS256 e seus irmãos — são a norma em produção, e verificá-los exige a chave pública do signatário, que uma ferramenta do lado cliente não pode obter por você; o decodificador diz exatamente isso em vez de adivinhar. Tokens com alg=none, a configuração famosamente insegura, são sinalizados como não protegidos, sem assinatura. Claims de expiração e emissão (exp, iat, nbf) aparecem na forma epoch bruta dentro do JSON do payload, exatamente como o token os carrega — a ferramenta não converte nem interpreta, porque conversão silenciosa é onde decodificadores mentem. Cole um token dos seus logs, do seu inspetor de rede ou dos seus testes e leia-o como o servidor leria.

Processado localmente no seu navegador

Cole o token completo — header.payload.signature.

Verifica assinaturas HS256/384/512 localmente — o segredo nunca sai do seu navegador.

Como o resultado é calculado?

Lendo um token de ID dos seus logs

Os logs de acesso do seu serviço contêm um token como o exemplo da RFC 7515 — um header declarando HS256, um payload com um subject, um nome e um tempo de emissão, e um segmento de assinatura. Decodifique-o para ler os claims como o servidor leria e, em seguida, cole o segredo compartilhado para confirmar que a assinatura realmente corresponde — um sub adulterado ou um iat expirado aparece como Assinatura inválida.

Exemplo de entrada e saída
Entrada Valor
Token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Segredo HMAC (opcional) your-256-bit-secret
Resultado {"sub":"1234567890","name":"John Doe","iat":1516239022} — Assinatura válida

Qual é a fórmula e suas premissas?

Serialização compacta JWT

JWT = base64url(header) + "." + base64url(payload) + "." + base64url(assinatura)

Termos da fórmula
Símbolo Significado
header o JSON do header: alg, typ e muitas vezes kid — o algoritmo de assinatura e o id da chave
payload os claims JSON: registrados (sub, iat, exp, nbf, iss, aud) mais claims personalizados
base64url base64 com caracteres seguros para URL (- e _) e sem preenchimento

RFC 7519 §3.1. A ferramenta decodifica os segmentos com base64url e formata o JSON; ela nunca reordena ou interpreta claims.

Verificação de assinatura HMAC

válida = verify(HMAC-{SHA-256|384|512}(segredo), base64url(header.payload), assinatura)

Termos da fórmula
Símbolo Significado
segredo o segredo HMAC compartilhado que você cola — usado só no navegador, nunca enviado
base64url(header.payload) a entrada de assinatura: os dois primeiros segmentos exatamente como o token os carrega
assinatura o terceiro segmento, decodificado para os bytes MAC brutos

crypto.subtle.verify realiza uma comparação em tempo constante, então uma divergência nunca vaza timing. Algoritmos assimétricos precisam da chave pública do signatário e são informados como não verificáveis localmente.

Quais são os erros mais comuns?

  • Confiar em um token porque ele decodifica — decodificar mostra os claims, não quem os assinou; apenas uma verificação de assinatura válida prova a origem, e só para tokens HMAC com o segredo certo.
  • Supor que tokens alg=none eram "inofensivos de decodificar" — eles não são assinados e devem ser rejeitados por qualquer biblioteca que os aceite.
  • Colar tokens de produção em decodificadores online que os enviam — esta ferramenta é totalmente local; muitos serviços web ficam com o seu token e seus claims.

Quais são as premissas e limitações?

  • A verificação de assinatura cobre apenas HMAC (HS256/384/512) — tokens assimétricos são informados como não verificáveis localmente.
  • Os claims são exibidos em bruto (segundos epoch para exp/iat/nbf); a ferramenta não os converte.
  • Tokens de acesso opacos não são JWTs e não podem ser decodificados.

De onde vêm os números?

Última revisão 12 de agosto de 2026 · Versão 1.0.0 · Toolivaro não garante conteúdo externo.

Perguntas frequentes

Meu token é enviado para algum lugar?

Não. A decodificação e a verificação de assinatura rodam inteiramente no seu navegador com WebCrypto — nenhuma requisição de rede é feita com seu token ou segredo. Isso torna a ferramenta segura até com tokens de produção que carregam claims reais de usuários.

Por que você não consegue verificar tokens RS256?

RS256 e as demais famílias assimétricas são verificadas com a chave pública do signatário, que fica no endpoint JWKS do emissor — uma ferramenta do lado cliente não tem como obter e confiar nessa chave por você de forma segura. O decodificador informa esses tokens como não verificáveis localmente em vez de fingir um resultado. Tokens HMAC (HS256/384/512) só precisam do segredo compartilhado, então esses são verificados quando você o fornece.

O que significa quando um token diz alg=none?

alg=none declara que o token não foi assinado de forma alguma. Bibliotecas que aceitam none são a origem de infames bypasses de autenticação. O decodificador sinaliza esses tokens como não protegidos, sem segmento de assinatura para verificar.

Por que exp e iat são mostrados como números brutos?

Porque é assim que o token os carrega — segundos epoch NumericDate conforme a RFC 7519. A ferramenta não converte nem interpreta claims silenciosamente: conversão silenciosa é onde decodificadores mentem, e o valor bruto é a verdade que o servidor vê.

Esta ferramenta consegue decodificar tokens de acesso OAuth 2.0?

Somente se forem JWTs. Muitos provedores (Okta, Auth0, Azure AD) emitem tokens de acesso JWT, e esses são decodificados aqui. Tokens opacos — strings aleatórias que são apenas identificadores — não têm JSON dentro e não são JWTs; nenhum decodificador pode transformá-los em claims.

Parte de Ferramentas de senhas, hash e segurança

Encontrou um erro ou tem uma correção? Informe — revisamos toda correção.

Foi útil?

Revisado pela equipe editorial da Toolivaro conforme nossa metodologia Metodologia · Política editorial