Published February 18, 2025 · 6 min read

JWT Decoder: How to Read JWT Tokens

If you work with APIs, authentication systems, or modern web applications, you've encountered JWT tokens. They appear as long, cryptic strings passed in HTTP headers, cookies, or URL parameters. But they're not encrypted — they're encoded. With the right tool, you can read exactly what's inside them. Here's everything you need to know about JWT tokens and how to decode them.

What Is a JWT Token?

JWT (JSON Web Token, pronounced "jot") is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. JWTs are commonly used for:

• Authentication — After login, the server issues a JWT that the client sends with each subsequent request to prove identity.
• Authorization — The JWT contains the user's roles and permissions, so the server knows what they're allowed to do.
• Information exchange — JWTs can carry any JSON payload, signed to ensure it hasn't been tampered with.

JWT Structure: The Three Parts

Every JWT consists of three parts separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

These three sections are:

1. Header — Contains the token type (JWT) and the signing algorithm (e.g., HS256, RS256).
2. Payload — Contains the claims — the actual data like user ID, email, roles, and expiration time.
3. Signature — A cryptographic signature that verifies the token hasn't been modified. Created using the header, payload, and a secret key.

The header and payload are simply Base64URL-encoded JSON. They're not encrypted — anyone can decode them. The signature is what provides security by ensuring the data hasn't been tampered with.

How to Decode a JWT Token

1. Open the JWT Decoder tool.
2. Paste your JWT token into the input field.
3. Instantly see the decoded header, payload, and signature information.

The decoder runs entirely in your browser. Your JWT tokens are never sent to any server — this is critical because tokens often contain sensitive authentication data.

Common JWT Claims

The payload section contains "claims" — key-value pairs of information. Some standard claims include:

• sub (Subject) — Who the token is about, typically a user ID.
• iss (Issuer) — Who created the token (e.g., your auth server's URL).
• aud (Audience) — Who the token is intended for.
• exp (Expiration) — Unix timestamp when the token expires. After this time, the token should be rejected.
• iat (Issued At) — Unix timestamp when the token was created.
• nbf (Not Before) — Unix timestamp before which the token should not be accepted.
• jti (JWT ID) — A unique identifier for the token, useful for preventing replay attacks.

Applications also add custom claims like email, name, roles, or permissions.

Why JWT Privacy Matters

Many popular JWT decoder websites send your token to their server for processing. This is a serious security risk. A JWT token often contains:

• User identity information (email, name, user ID)
• Authorization scopes and permissions
• Session information that could be used for impersonation
• Organization and tenant identifiers

Sending a valid JWT to a third-party server is essentially sharing your authentication credentials. Our browser-based JWT decoder eliminates this risk entirely — the decoding happens in JavaScript on your device.

JWT Debugging Tips

• Check expiration first — If an API returns 401, decode the token and check the exp claim. Expired tokens are the most common auth issue.
• Verify the audience — The aud claim must match what the API expects. Mismatched audiences cause rejection.
• Inspect the algorithm — The header's alg field tells you the signing algorithm. Make sure it matches your server's configuration.
• Look for clock skew — If tokens expire unexpectedly, there may be a time difference between the issuer and verifier servers.
• Check custom claims — Missing or incorrect role/permission claims are a frequent cause of 403 Forbidden errors.

JWT Security Best Practices

• Keep tokens short-lived — Set exp to minutes or hours, not days or weeks.
• Don't store sensitive data — Remember, the payload is not encrypted. Don't put passwords, credit card numbers, or secrets in JWTs.
• Use HTTPS always — JWTs in transit should always be encrypted by TLS.
• Validate the signature — Always verify the signature server-side. Never trust a JWT without validation.
• Use strong signing keys — For HMAC algorithms, use at least 256-bit random keys.

Related Developer Tools

• Base64 Encoder/Decoder — JWTs use Base64URL encoding. Understand the underlying encoding.
• Unix Timestamp Converter — Convert exp and iat timestamps to human-readable dates.
• JSON Formatter — Pretty-print the decoded JSON payload.
• Hash Generator — Generate hashes for testing and development.

All tools on This 2 That run locally in your browser. Your data never leaves your device.