Como decodificar e verificar tokens JWT no seu navegador

Se você já trabalhou com qualquer sistema de autenticação web moderno — OAuth 2.0, OpenID Connect ou uma API personalizada — você quase certamente já encontrou tokens JWT. Eles aparecem em cabeçalhos Authorization, em cookies, no local storage e em sessões de depuração às 2 da manhã, quando um fluxo de login está misteriosamente falhando. Entender o que um JWT realmente contém, como lê-lo e como identificar problemas comuns torna a depuração de autenticação drasticamente mais rápida.

O Decodificador de JWT do BrowseryTools permite que você cole qualquer token JWT e veja instantaneamente seu cabeçalho, payload e status de expiração decodificados — tudo no seu navegador, com o token nunca saindo do seu dispositivo.

O que é um JWT?

JWT significa JSON Web Token, definido na RFC 7519. Um JWT é um token compacto e seguro para URLs que codifica um conjunto de claims — afirmações sobre um sujeito, tipicamente um usuário — em um formato que pode ser verificado e confiável. A propriedade-chave de um JWT é que ele é autocontido: o próprio token carrega todas as informações de que um servidor precisa para autenticar uma requisição, sem uma consulta ao banco de dados.

Um JWT se parece com isto:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfODQyMTkiLCJuYW1lIjoiSmFuZSBEb2UiLCJlbWFpbCI6ImphbmUuZG9lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsidXNlciIsImVkaXRvciJdLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImlhdCI6MTczODM2ODAwMCwiZXhwIjoxNzM4MzcxNjAwLCJqdGkiOiI3ZjNhOWI0Yy0xZDJlLTQ1NmYtYWJjZC04OTAxMjM0NTY3ODkifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

À primeira vista, parece algo sem sentido. Mas tem uma estrutura muito precisa: três seções codificadas em Base64URL separadas por pontos. Cada seção tem um propósito específico.

A estrutura de três partes: Cabeçalho.Payload.Assinatura

Parte 1: O cabeçalho

O primeiro segmento, antes do primeiro ponto, é o cabeçalho. É um objeto JSON codificado em Base64URL que descreve o tipo do token e o algoritmo de assinatura. Decodificado, o cabeçalho do exemplo acima fica assim:

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

O campo alg especifica o algoritmo de assinatura. Valores comuns que você encontrará são:

• HS256 — HMAC com SHA-256. Usa uma chave secreta compartilhada. Tanto o emissor quanto o verificador devem ter o mesmo segredo. Comum em aplicações monolíticas.
• RS256 — Assinatura RSA com SHA-256. Usa um par de chaves pública/privada. O emissor assina com a chave privada; os verificadores conferem com a chave pública. Comum em sistemas distribuídos e provedores OAuth.
• ES256 — ECDSA com P-256 e SHA-256. Como o RS256, mas usando curvas elípticas — chaves mais curtas, mesmo nível de segurança. Preferido em sistemas modernos de alto desempenho.
• none — Sem assinatura. Nunca aceite isto em produção. Uma vulnerabilidade de segurança notória surge quando os servidores aceitam tokens não assinados porque o cliente alterou o alg para "none".

Parte 2: O payload

O segundo segmento é o payload — os dados de fato que o token carrega. Ele também é um objeto JSON codificado em Base64URL. O payload decodificado do nosso exemplo:

{
  "sub": "usr_84219",
  "name": "Jane Doe",
  "email": "jane.doe@example.com",
  "roles": ["user", "editor"],
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1738368000,
  "exp": 1738371600,
  "jti": "7f3a9b4c-1d2e-456f-abcd-890123456789"
}

O payload contém dois tipos de claims: as claims registradas definidas pela especificação do JWT e as claims privadas/personalizadas adicionadas pela sua aplicação (comoname, email e roles acima).

Parte 3: A assinatura

O terceiro segmento é a assinatura. Ela é calculada pegando o cabeçalho codificado em Base64URL, um ponto, o payload codificado em Base64URL e assinando o resultado com o algoritmo e a chave especificados no cabeçalho. Para o HS256:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

A assinatura garante a integridade: se alguém modificar até um único caractere no cabeçalho ou no payload depois que o token é emitido, a assinatura se torna inválida e a verificação falha. Sem conhecer o segredo de assinatura (ou a chave privada do emissor para RS256/ES256), um atacante não consegue forjar um token válido.

Referência de claims padrão do JWT

Por que a claim exp é fundamental

A claim exp é um timestamp Unix — o número de segundos desde 1º de janeiro de 1970 (UTC). No nosso exemplo, "exp": 1738371600. Para converter isso em uma data legível por humanos, você pode usar JavaScript:

new Date(1738371600 * 1000).toUTCString()
// → "Sat, 01 Feb 2026 01:00:00 GMT"

A expiração do JWT é a primeira coisa a verificar quando um token está sendo rejeitado. Um token que era válido ontem falhará hoje se seu exp estiver no passado — isso é por design. Tokens de vida curta (de 15 minutos a 1 hora) limitam a janela de dano caso um token seja roubado. Tokens de vida mais longa (dias ou semanas) são mais convenientes, mas mais perigosos se comprometidos.

O Decodificador de JWT do BrowseryTools lê automaticamente as claims exp e iat e as exibe como datas legíveis por humanos junto com os timestamps Unix brutos, para que você nunca precise fazer a conta de cabeça manualmente.

Cenários comuns de depuração de JWT

Token expirado (401 Unauthorized)

O erro de JWT mais comum. O servidor rejeitou o token porque o horário atual passou do valor de exp. Solução: implemente um fluxo de renovação de token usando um refresh token de vida mais longa ou simplesmente reautentique. Cole o token no decodificador para confirmar exatamente quando ele expirou.

Audiência errada

Se a sua API valida a claim aud e o token foi emitido para uma audiência diferente (por exemplo, um token emitido para https://api-staging.example.com sendo enviado para https://api.example.com), o servidor o rejeitará. Decodifique o token e inspecione o campoaud para confirmar que ele corresponde ao que o serviço receptor espera.

Incompatibilidade de algoritmo

Se o seu servidor espera RS256 mas recebe um token assinado com HS256 (ou vice-versa), a validação falha. Isso pode acontecer durante a rotação de chaves ou ao trocar de provedor de autenticação. Verifique o campo alg no cabeçalho decodificado em relação ao que o seu servidor está configurado para aceitar.

Assinatura inválida

Se o payload foi adulterado — mesmo que um único caractere tenha sido alterado — a assinatura não vai corresponder. Isso também acontece se você estiver usando o segredo errado ou a chave pública errada para verificar. Decodificar o cabeçalho e o payload (o que não requer segredo) permite que você pelo menos inspecione o que o token afirma, mesmo que não consiga verificar sua autenticidade no lado do cliente.

JWT vs tokens de sessão: quando usar cada um

Os JWTs e os tokens de sessão tradicionais resolvem o mesmo problema — identificar um usuário autenticado ao longo de várias requisições — mas fazem isso de forma diferente, e nenhum é universalmente melhor.

Os tokens de sessão tradicionais são strings aleatórias opacas (por exemplo, um UUID) armazenadas no lado do servidor em um repositório de sessões (Redis, banco de dados). A cada requisição, o servidor consulta o token no repositório e recupera os dados do usuário. O servidor tem total controle: invalidar uma sessão revoga o acesso imediatamente.

Os JWTs são stateless (sem estado). O servidor emite um token assinado e não mantém registro dele. A cada requisição, o servidor verifica a assinatura e confia nas claims sem nenhuma consulta ao banco de dados. Isso escala horizontalmente sem estado compartilhado — qualquer servidor com a chave de verificação pode autenticar a requisição. A contrapartida: você não consegue revogar um JWT imediatamente antes de ele expirar (a menos que implemente uma lista de bloqueio de tokens, o que reintroduz estado).

• Use JWTs para microsserviços stateless, sistemas distribuídos, APIs móveis e autenticação entre domínios (fluxos OAuth/OIDC). Mantenha os tempos de expiração curtos.
• Use tokens de sessão quando você precisar de capacidade de revogação imediata (logout, suspensão de conta, incidentes de segurança) ou quando todos os seus serviços compartilharem um repositório de sessões rápido.

Como usar o Decodificador de JWT do BrowseryTools

Abra o Decodificador de JWT e cole seu token no campo de entrada. A ferramenta divide o token imediatamente nos dois pontos e exibe:

• Painel do cabeçalho: O JSON decodificado mostrando alg, typ e quaisquer outros campos do cabeçalho. Útil para identificar o algoritmo de assinatura rapidamente.
• Painel do payload: O JSON decodificado completo com todas as claims. Os timestamps são exibidos tanto no formato Unix bruto quanto em datas UTC legíveis por humanos, para que você veja a expiração imediatamente sem conversão mental.
• Status de expiração: Um indicador claro mostrando se o token está atualmente válido, já expirado ou ainda não ativo (com base em nbf). Se expirado, você vê exatamente há quanto tempo ele expirou.
• Segmento da assinatura: A assinatura bruta codificada em Base64URL, exibida para referência. A ferramenta não verifica a assinatura (isso requer o segredo ou a chave pública), mas decodifica e exibe todas as informações de que você precisa para a depuração.

Não há envio de formulário, nenhuma requisição ao servidor, nenhum acesso à área de transferência além do que você cola explicitamente. A análise do token acontece inteiramente em JavaScript rodando na aba do seu navegador.

Decodifique seu token JWT agora

Seja depurando um token expirado, inspecionando claims de um provedor OAuth, verificando quais papéis foram concedidos a um usuário ou simplesmente tentando entender o que o seu sistema de autenticação está de fato emitindo — o Decodificador de JWT do BrowseryTools dá a você as respostas instantaneamente. Sem registro, sem extensões para instalar, sem dados enviados para lugar nenhum.