JWT Decoder & Debugger

What a JWT Actually Contains — and Why You Need to See It

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe string that carries verifiable claims between parties. When a user logs into a web application, the server typically issues a JWT that the client stores and sends with every subsequent request. The token contains claims — structured JSON data about the user, their permissions, and the token's validity period. Because the Header and Payload are Base64URL-encoded (not encrypted), anyone with the token can read their contents by decoding them. Our free online JWT decoder does exactly this — paste any JWT and instantly see the structured Header and Payload as formatted JSON, with all registered claims highlighted and expiry status checked against the current time.

The Three Parts of a JWT Token

A JWT has the structure xxxxx.yyyyy.zzzzz — three sections separated by dots, each Base64URL-encoded. The Header (first section) is a JSON object specifying the token type ("JWT") and the signing algorithm used — typically HS256 (HMAC-SHA256 with a shared secret) or RS256 (RSA with a private/public key pair). The Payload (second section) contains the claims — both registered standard claims (sub, iss, aud, exp, iat, nbf, jti) and any custom claims the application adds (user roles, permissions, email address). The Signature (third section) is a cryptographic proof that the Header and Payload were not modified after the token was issued. Decoding only reads the Header and Payload — verifying the Signature requires the signing key, which this client-side tool does not use.

Decoding vs Verifying — Never Confuse These

This is the most important concept in JWT security. Decoding reads the contents — it only requires Base64URL decoding, which anyone can do. Verifying proves the contents are trustworthy — it requires checking the cryptographic signature against the expected key. In a web application, your server must verify the signature before trusting any claim in the payload. An attacker can create a JWT with any payload they want — including claiming to be an admin user or a different user ID — and it will decode perfectly. Without signature verification, you cannot distinguish a legitimate token from a forged one. The alg: "none" vulnerability — where some old JWT libraries skip verification entirely when the algorithm is declared as "none" — caused major security incidents precisely because of this confusion. Use this tool to decode and inspect tokens; use a server-side JWT library to verify them.

The Seven Registered Claims — What Each One Means

• iss (Issuer): Identifies who issued the token — typically a URL like "https://auth.myapp.com". Your server should verify this matches the expected issuer to prevent tokens from a different system being accepted
• sub (Subject): The principal the token is about — typically a user ID. This is the primary identifier used to look up the user in your database
• aud (Audience): Identifies the intended recipients — your API should reject tokens where the aud claim does not match its own identifier
• exp (Expiration Time): A Unix timestamp after which the token must not be accepted. The tool converts this to a human-readable UTC date and shows whether the token has expired
• iat (Issued At): The Unix timestamp when the token was created. Useful for calculating token age and detecting suspiciously old tokens
• nbf (Not Before): The Unix timestamp before which the token must not be accepted. Clock skew between servers is a common cause of nbf failures in distributed systems
• jti (JWT ID): A unique identifier for the token. Used to implement token revocation — store used JTIs and reject any token whose JTI appears in the revocation list

When to Use a JWT Decoder During Development

• Debugging authentication failures: Users being logged out unexpectedly? Decode their token to check whether exp has passed. The tool shows the exact expiry moment in UTC so you can compare it to when the issue occurred
• Verifying claim values during development: Inspect sub, iss, aud and custom claims to confirm your auth server is issuing the correct payload before writing authorisation logic that depends on it
• Confirming the algorithm: The alg field in the Header tells you the signing algorithm. Verify this matches what your server expects — an unexpected algorithm change can indicate a configuration issue or attack
• Diagnosing nbf errors: Not Before failures are caused by clock skew between the token issuer and verifier. Decode to see the exact nbf timestamp and compare to the failing server's clock
• Reading third-party tokens: When integrating OAuth2 providers (Google, Auth0, Okta, GitHub), decode their ID tokens and access tokens to understand the exact claim structure before writing code that depends on it
• Security auditing: Check whether tokens contain sensitive data — PII, passwords, internal system details — that should not be in the payload. JWT payloads are readable by anyone who has the token, so sensitive data requires JWE (JSON Web Encryption) not just JWS (JSON Web Signature)

Common JWT Security Vulnerabilities to Watch For

The alg: none vulnerability is the most dangerous: some old JWT libraries accept tokens declaring "alg: none" and skip signature verification entirely. Always explicitly whitelist algorithms your server accepts and reject the none algorithm. Algorithm confusion attacks target RSA (RS256) implementations — an attacker changes the algorithm from RS256 to HS256 and signs the payload with the public key (which is known). The server then verifies an HS256 signature using the public key as the HMAC secret, accepting the forged token. Storing JWTs in localStorage makes them accessible to any JavaScript running on your page, including malicious scripts injected via XSS. Prefer httpOnly cookies. For systems requiring hard revocation (logout, password change), implement a token blacklist using the jti claim. Complement this tool with our AES Encryption tool for encrypting sensitive values before embedding them in token payloads.

Your Token Is Never Transmitted — Complete Privacy

All decoding uses atob() and JSON.parse() entirely in your browser tab. Your JWT token — including the user ID, email, role claims and any other payload data — is never sent to ToollyX servers. This is safe for decoding real production tokens during debugging sessions. Note that JWT payloads are Base64URL-encoded, not encrypted: the data is readable by anyone who possesses the token, which is why tokens must be transmitted exclusively over HTTPS and stored securely.

✓Verified by ToollyX Team · Last updated June 2026