Loading tool...
Decode and inspect JSON Web Tokens (JWT) without the secret key with our free JWT Decoder, essential for debugging authentication issues and understanding token structure. JWTs are commonly used for authentication and authorization in modern web applications, APIs, and microservices. A JWT consists of three Base64-encoded parts (header, payload, signature) separated by dots—while the signature is cryptographically protected, the header and payload are simply Base64-encoded and readable without the secret key. This tool decodes JWT tokens instantly, showing you the header (containing algorithm information), payload (containing user claims and token data), and expiration status. Understanding token contents is crucial for debugging authentication problems, verifying that the right claims are included, checking token expiration times, and learning how JWT-based authentication systems work. The tool automatically identifies the signing algorithm, checks whether tokens have expired, displays all claims clearly, and formats JSON for easy reading. Perfect for developers debugging authentication flows, system administrators investigating login issues, security professionals analyzing tokens, and anyone working with JWT-protected APIs and applications.
Inspect JWT tokens to verify correct user claims, check expiration times, and diagnose authentication failures in web applications.
Decode API tokens to confirm they contain required claims and have correct permissions before making authenticated API requests.
During API development, decode tokens returned from auth endpoints to verify they contain expected structure and claims for integration testing.
Analyze JWT tokens in security audits to verify proper claim usage, appropriate expiration times, and correct encryption algorithms are being used.
Understand how JWT authentication works by decoding real tokens and examining header, payload, and signature components.
When troubleshooting token-based communication between microservices, decode tokens at each step to track claim propagation and verify correct token handling.
JSON Web Tokens (JWTs, pronounced "jots") were introduced as RFC 7519 in 2015, though the concept evolved from earlier work on the JOSE (JSON Object Signing and Encryption) framework. JWTs were designed to solve a specific problem in distributed web architectures: how can one service verify that a user has been authenticated by another service without making a network call back to the authenticating service? The answer is a self-contained, cryptographically signed token that carries all the necessary information within itself.
A JWT consists of three parts separated by periods: the header, the payload, and the signature. The header is a JSON object specifying the token type ("JWT") and the signing algorithm (e.g., "HS256" for HMAC-SHA256 or "RS256" for RSA-SHA256). The payload is a JSON object containing "claims"—statements about the user and metadata about the token. The signature is computed by applying the specified algorithm to the encoded header and payload using a secret key (for HMAC) or private key (for RSA/ECDSA). Each of the three parts is Base64URL-encoded (a URL-safe variant of Base64) and concatenated with dots.
The claim system is central to JWT's design. The specification defines seven registered claims: "iss" (issuer), "sub" (subject), "aud" (audience), "exp" (expiration time), "nbf" (not before), "iat" (issued at), and "jti" (JWT ID). These provide standardized metadata that receiving systems can use to validate tokens. Beyond these, applications define custom claims for their specific needs—user roles, permissions, organization IDs, subscription tiers, or any other data the receiving service needs to make authorization decisions without database lookups.
A crucial and often misunderstood aspect of JWTs is that the header and payload are not encrypted—they are merely Base64URL-encoded. Anyone who possesses a JWT can decode and read its contents instantly. The signature protects against tampering (you cannot modify claims without invalidating the signature) but not against reading. This means sensitive information like passwords, social security numbers, or credit card numbers should never be placed in JWT claims. For tokens that require confidentiality, the JWE (JSON Web Encryption) standard provides encrypted tokens, though they are significantly less common in practice.
The choice between symmetric (HMAC) and asymmetric (RSA/ECDSA) signing algorithms has architectural implications. HMAC uses a single shared secret for both signing and verification, which is simpler but requires every verifying service to possess the secret. RSA and ECDSA use public-private key pairs: only the authentication service needs the private key to sign tokens, while any service can verify tokens using the freely distributable public key. This asymmetric model is essential in microservices architectures where dozens of services need to verify tokens without sharing secrets.
JWTs have attracted significant criticism regarding security. Stateless tokens cannot be revoked individually—once issued, a JWT remains valid until it expires, which means a compromised token cannot be easily invalidated. The "none" algorithm vulnerability, where an attacker modifies the header to specify no signature, historically affected poorly implemented JWT libraries. Token size can also be a concern, as JWTs with many claims can become quite large, and since they are typically sent with every HTTP request, they add bandwidth overhead compared to simple session IDs.
Yes. JWT header and payload are Base64URL-encoded, not encrypted. Anyone can decode and read them. The secret key is only needed to verify the signature, not to read the contents.
Standard claims include: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Custom claims can contain any application-specific data.
The tool checks the "exp" (expiration) claim in the payload and compares it to the current time. Expired tokens are clearly flagged so you can quickly identify authentication issues.
Yes, all decoding happens locally in your browser. No data is sent to any server. However, remember that JWTs may contain sensitive information, so avoid sharing decoded contents publicly.
All processing happens directly in your browser. Your files never leave your device and are never uploaded to any server.