// how-to guide

How to Decode a JWT Token

Inspect and decode JSON Web Tokens to view the header, payload, and signature without any server-side processing.

1

Paste your JWT

Copy the full JWT string (the three dot-separated segments) and paste it into the input field.
2

View the decoded parts

The tool splits the token into its header, payload, and signature. The header and payload are decoded from Base64 and displayed as formatted JSON.
3

Check claims and expiration

Review the payload claims including iss, sub, exp, and iat. The tool highlights whether the token is expired.
4

Copy individual sections

Copy the header, payload, or full decoded output separately for use in debugging or documentation.

JSON Web Tokens show up everywhere — OAuth flows, API authentication, single sign-on systems, and session management. When you need to quickly check what claims a token carries or whether it has expired, the JWT Decoder lets you inspect it without writing any code or hitting a server.

Understanding JWT structure

A JWT is made up of three parts separated by dots: header.payload.signature. The header and payload are Base64url-encoded JSON objects, and the signature is a cryptographic hash that verifies the token has not been tampered with.

The header typically contains the algorithm used for signing (like HS256 or RS256) and the token type. The payload holds the claims — standard ones like iss (issuer), sub (subject), exp (expiration timestamp), and iat (issued at), along with any custom claims the application adds. The signature is computed from the header, payload, and a secret key or private key.

Why this matters

Decoding a JWT in the browser is safe because you are only reading the Base64-encoded data — you are not verifying the signature. However, you must understand an important security principle: never trust a JWT on the client side alone. A decoded JWT tells you what the token claims, but only server-side signature verification confirms those claims are authentic. An attacker can craft a JWT with any payload they want — only the signature check catches the forgery.

This means client-side JWT decoding is useful for debugging and UI purposes (like showing the user’s name or checking if a token looks expired before making an API call), but all authorization decisions must happen on the server.

Tips and best practices

Check the exp claim first when debugging authentication failures. Token expiration is the most common reason API calls start returning 401 errors.
Look at the alg field in the header. If it says none, that is a red flag — it means the token is unsigned and should be rejected by any properly configured server.
Compare iat and exp to understand the token’s lifetime. Short-lived tokens (5-15 minutes) are more secure but require a refresh token flow.
Watch for clock skew. JWT timestamps are Unix epoch seconds. If your server and auth provider clocks are slightly out of sync, tokens may appear expired prematurely.
Never paste production tokens into untrusted websites. Use a tool you trust, or decode locally with echo '<payload>' | base64 -d in your terminal.

Common issues

“Invalid token” errors: Make sure you are pasting the complete token, including all three dot-separated parts. Copying from logs sometimes truncates long strings.
Expired tokens that look valid: The exp value is a Unix timestamp in seconds, not milliseconds. If you are comparing it manually, make sure you are using the right unit.
Unexpected claims: Some identity providers nest user info inside a custom claim like https://example.com/claims rather than using standard claim names. Check your provider’s documentation if expected fields are missing.