Decodificar JWT Online
Decodifique tokens JWT no seu navegador sem enviar dados a nenhum servidor.
Por que usar
Depure tokens JWT instantaneamente
100% privado
A decodificação acontece no seu navegador. Seu token nunca sai do seu dispositivo.
Instantâneo
Decodificação em tempo real conforme você digita. Sem botões, sem espera.
JSON formatado
Header e payload exibidos como JSON legível com realce de sintaxe adequado.
Todos os tipos de JWT suportados
Funciona com HS256, RS256, ES256 e qualquer algoritmo do padrão JOSE.
Como funciona
Três passos, sem complicação
Cole o seu token JWT
Copie e cole qualquer JWT no campo de entrada. O formato consiste em três partes separadas por pontos: header.payload.signature.
Decodificação instantânea
O header e o payload são decodificados de Base64URL e exibidos como JSON formatado. Veja o tipo de algoritmo, o emissor, a expiração e todas as claims.
Analise os dados
Revise cada campo do payload: iss (issuer), sub (subject), exp (expiration), iat (issued at), aud (audience) e quaisquer claims personalizadas.
Perguntas frequentes
Ficou com dúvidas?
JWT (JSON Web Token) é um padrão aberto (RFC 7519) que define uma forma compacta e autossuficiente de transmitir informações entre partes como um objeto JSON. O token é assinado digitalmente, permitindo verificar sua autenticidade. É amplamente usado para autenticação e autorização em APIs REST e aplicações web modernas.
Quando um usuário faz login, o servidor cria um JWT assinado com uma chave secreta (HS256) ou chave privada (RS256) e o envia ao cliente. O cliente armazena o token (tipicamente em memória ou no localStorage) e o inclui em cada requisição como Authorization: Bearer token. O servidor verifica a assinatura do token sem consultar um banco de dados, tornando o JWT um mecanismo de autenticação sem estado que escala bem em sistemas distribuídos.
Um JWT é assinado, não criptografado. Isso significa que qualquer pessoa pode decodificar o payload e ler seu conteúdo, então nunca inclua senhas, cartões de crédito ou dados sensíveis no payload. A assinatura garante a integridade (ninguém pode modificar o token sem invalidá-lo), mas não a confidencialidade. Se você precisar criptografar o conteúdo, use JWE (JSON Web Encryption).
Claims são declarações sobre o sujeito do token. As claims registradas pela RFC 7519 incluem: iss (issuer), sub (subject), exp (expiration, timestamp Unix), iat (issued at), aud (audience), nbf (not before) e jti (JWT ID). Além dessas, você pode incluir quaisquer claims personalizadas que seu aplicativo necessite.
Não sem invalidá-lo. Se você modificar qualquer parte do header ou payload e não tiver a chave secreta para assinar novamente, a assinatura resultante estará errada e o servidor rejeitará o token. No entanto, existem vulnerabilidades conhecidas: o ataque alg:none (onde o header declara que não há algoritmo para contornar a verificação) e a confusão de algoritmos RS256 e HS256. Sempre use uma biblioteca JWT bem mantida que trate explicitamente esses casos.
Cookies de sessão armazenam um ID no servidor (com estado), enquanto o JWT contém todas as informações no próprio token (sem estado). O JWT escala melhor em arquiteturas distribuídas e microsserviços porque não exige sessões compartilhadas. No entanto, o JWT tem desvantagens: você não pode revogar um token antes de ele expirar sem infraestrutura adicional (blacklist) e, se o token for roubado, ele permanece válido até expirar. Para a maioria das aplicações web tradicionais, cookies de sessão httpOnly continuam sendo a escolha padrão mais segura.
JWT: história, estrutura técnica e segurança em profundidade
O JSON Web Token foi padronizado pelo IETF em maio de 2015 como RFC 7519, parte do framework JOSE (JSON Object Signing and Encryption). O JOSE também inclui JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517) e JWA (JSON Web Algorithms, RFC 7518). O trabalho no padrão começou em 2011, liderado por Mike Jones (Microsoft), John Bradley e Nat Sakimura. Antes do JWT, os desenvolvedores dependiam do SAML (Security Assertion Markup Language), um padrão baseado em XML consideravelmente mais verboso e complexo.
Um JWT é composto por três partes codificadas em Base64URL separadas por pontos. O Base64URL difere do Base64 padrão substituindo o sinal de mais por hífen e a barra por underscore, omitindo o preenchimento com sinal de igual, tornando-o seguro para uso em URLs e cabeçalhos HTTP sem codificação adicional. O header especifica o tipo do token e o algoritmo de assinatura. Os algoritmos mais comuns são HS256 (HMAC-SHA256, chave simétrica), RS256 (RSA-SHA256, chave assimétrica), ES256 (ECDSA-SHA256, curva P-256) e o perigoso none (sem assinatura, que nunca deve ser aceito em produção).
As vulnerabilidades mais críticas de JWT estão bem documentadas no OWASP API Security Top 10. A vulnerabilidade alg:none (CVE-2015-9235 em diversas bibliotecas) permite que um atacante modifique o header para declarar que nenhuma assinatura é necessária, fazendo o servidor aceitar qualquer payload arbitrário se a biblioteca não validar explicitamente o algoritmo. A confusão de algoritmos RS256 e HS256 ocorre quando um servidor configurado para RS256 também aceita HS256: o atacante pode usar a chave pública RSA (que é, por definição, pública) como chave secreta HMAC para assinar tokens fraudulentos. Bibliotecas modernas como jose, python-jose e jsonwebtoken resolvem isso exigindo que o algoritmo seja especificado explicitamente na verificação.