⚠️ Aviso de segurança: Nunca cole tokens JWT de produção em ferramentas online que processam no servidor. Nosso decodificador é 100% client-side — você pode verificar na aba "Rede" do DevTools que nenhuma requisição é feita ao colar seu token.
O que é JWT e por que é o padrão de autenticação da web moderna
O JWT (JSON Web Token), pronunciado "jot", é um padrão aberto (RFC 7519) para transmitir informações de forma compacta e auto-contida entre partes como um objeto JSON. É usado massivamente em autenticação stateless, autorização de APIs REST, Single Sign-On (SSO) e troca de informações entre microsserviços.
A popularidade do JWT explodiu com a ascensão das arquiteturas stateless e microserviços. Em vez de manter sessões no servidor (que não escalam horizontalmente), o JWT permite que o servidor valide a identidade do usuário apenas com a chave secreta — sem consultar um banco de dados de sessão.
Estrutura completa de um JWT: as 3 partes
| Parte |
Conteúdo |
Codificação |
Exemplo |
| Header |
Algoritmo de assinatura e tipo do token |
Base64URL |
{"alg":"HS256","typ":"JWT"} |
| Payload |
Claims: dados do usuário + metadados |
Base64URL |
{"sub":"123","name":"João","iat":1516239022} |
| Signature |
HMAC ou RSA do header+payload com chave secreta |
Binário em Base64URL |
HMACSHA256(base64(header)+"."+base64(payload), secret) |
Por que o payload do JWT não é criptografado — e o que fazer sobre isso
Este é um dos erros de segurança mais comuns com JWT: o payload não é criptografado — apenas codificado em Base64URL, que qualquer pessoa pode decodificar. Isso significa que qualquer dado no payload do JWT pode ser lido por quem tiver acesso ao token — seja um usuário com o token, um proxy, ou um log de servidor. Nunca coloque no payload informações sensíveis como senhas, dados de cartão, CPF completo ou qualquer PII que não deva ser exposta.
O JWT garante apenas que o token não foi modificado (integridade via assinatura). Se precisar de confidencialidade (payload criptografado), use JWE (JSON Web Encryption) em vez de JWT simples, ou trafegue sempre via HTTPS e minimize os dados no payload.
É seguro usar um site online para decodificar JWT?
Depende de como o site processa o token. Se a decodificação acontece no servidor, seu token é enviado pela rede para um sistema externo — isso é um risco real de segurança, especialmente se o token contiver informações de usuário, permissões ou outros dados sensíveis. O Gera&Convert processa tokens JWT 100% no seu navegador: a decodificação usa apenas atob() em JavaScript. Para confirmar, abra o DevTools (F12) → aba Rede e cole um token — você não verá nenhuma requisição de rede sendo feita.
Perguntas frequentes — JWT Decoder
É seguro colocar um JWT em um site online?▼
Depende fundamentalmente do processamento. Sites que enviam o token para seus servidores representam um risco — seus logs podem armazenar o token. O Gera&Convert decodifica 100% no browser (JavaScript puro). Mas como precaução, prefira sempre ferramentas offline para tokens de produção com dados sensíveis: jwt.ms (Microsoft, client-side) ou o próprio devtools do browser.
JWT pode ser falsificado?▼
A assinatura do JWT previne falsificação — qualquer alteração no header ou payload invalida a assinatura. Porém, vulnerabilidades ocorrem quando: o servidor aceita o algoritmo "none" (sem assinatura), usa HS256 com chave fraca, ou tem falha na verificação da assinatura. Sempre valide o algoritmo no header antes de aceitar o token.
Qual a validade de um JWT e como controlar?▼
A validade é definida pelo claim exp (expiration), um timestamp Unix. Ex: "exp": 1716239022. O servidor deve rejeitar tokens com exp no passado. O claim iat (issued at) indica quando foi criado, e nbf (not before) quando começa a ser válido. Para tokens de curta duração, use 15-60 minutos para access tokens e 7-30 dias para refresh tokens.
Qual a diferença entre JWT e opaque tokens?▼
JWT são tokens self-contained — carregam as informações necessárias para validação sem consultar o banco. Opaque tokens são strings aleatórias que precisam ser consultadas no banco a cada requisição. JWT escala melhor (sem I/O de banco na validação), mas não podem ser revogados facilmente. Opaque tokens permitem revogação imediata mas geram mais carga no banco.
Como revogar um JWT antes do seu tempo de expiração?▼
O JWT não tem mecanismo de revogação nativo. Estratégias comuns: (1) blacklist de JTI (JWT ID) revogados em Redis com TTL igual ao exp do token, (2) usar access tokens com vida curta (15 min) + refresh tokens para renovação, (3) incluir uma versão de token no payload e invalidar mudando a versão no banco, (4) usar opaque tokens para casos que precisam de revogação imediata.
O que são JWT Claims e quais são os padrões?▼
Claims são os campos do payload. Claims registrados (padronizados): iss (issuer/emissor), sub (subject/usuário), aud (audience/destinatário), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID único). Claims públicos são registrados na IANA. Claims privados são customizados pela sua aplicação (ex: role, permissions, email).
JWT é adequado para autenticação mobile?▼
Sim. JWT é especialmente popular em apps mobile porque elimina a necessidade de cookies (que têm problemas em contexto mobile). Armazene o access token em memória (nunca em localStorage/AsyncStorage) e o refresh token no Keychain (iOS) ou EncryptedSharedPreferences (Android). Nunca armazene tokens em campos persistentes não criptografados.
Como implementar refresh token com JWT em Node.js?▼
Use dois endpoints: /auth/login (retorna access + refresh token), /auth/refresh (recebe refresh token válido, retorna novo access token). O access token tem vida curta (15-60 min), o refresh token tem vida longa (7-30 dias) e é armazenado no banco. Ao revogar o refresh token no banco, o usuário efetivamente sai do sistema.
Por que o JWT tem 3 partes separadas por ponto?▼
O formato xxx.yyy.zzz é intencional: header.payload.signature. A separação por pontos permite parsing eficiente sem precisar saber o tamanho de cada parte. O servidor pode verificar a assinatura recalculando HMAC(base64(header)+"."+base64(payload), secret) e comparando com a terceira parte — se baterem, o token é autêntico e íntegro.
JWT e LGPD: quais cuidados são necessários?▼
Pela LGPD, dados pessoais em JWT (nome, e-mail, CPF) são tratados como dados pessoais mesmo que codificados. Minimização de dados: inclua no payload apenas o necessário. Direito ao esquecimento: lembre que JWTs válidos continuam funcionando até expirar mesmo após exclusão do usuário — use blacklist ou vida curta + refresh tokens. Armazenamento de logs: desative logging de Authorization headers em proxies e load balancers.