JWT Decoder
Decode JSON Web Tokens instantly to view their header and payload claims.
Decode, Inspect, and Debug JSON Web Tokens (JWT) Safely
If you build or maintain modern web applications, you encounter JSON Web Tokens (JWTs) every single day. Whether you are using NextAuth, Supabase, Firebase, Auth0, or custom OAuth 2.0 backends, JWTs have become the standard mechanism for transmitting verified user identity claims between clients and servers.
During development, auth issues inevitably strike. A user gets an unexpected `403 Forbidden` response, a frontend route refuses to render, or sessions mysteriously expire every ten minutes.
To diagnose what is going wrong, you need to open the token and examine its contents: Has the expiration timestamp (`exp`) passed? Is the correct user role or permission array embedded in the claims? Did the backend sign it with RS256 or HS256?
Our free online JWT Decoder breaks down any JWT into its three foundational components—Header, Payload, and Signature—translates cryptic epoch timestamps into your local timezone, and executes 100% locally in your browser so production authentication tokens are never exposed to external servers.
The Anatomy of a JWT: Three Parts Separated by Dots
A JSON Web Token consists of three distinct Base64URL-encoded strings separated by periods (`.`):
1. Header (Red)
Specifies the cryptographic signing algorithm (such as `HS256` or `RS256`) and the token type (`JWT`).
2. Payload / Claims (Purple)
Contains the user data and claims. Standard registered claims include `sub` (subject/user ID), `iat` (issued at), and `exp` (expiration timestamp).
3. Signature (Blue)
Generated by hashing the encoded header and payload with a private secret key. It ensures that the token has not been tampered with in transit.
Critical Security Rule: Base64 is NOT Encryption!
⚠️ Never store private passwords, API keys, or credit cards in a JWT payload!
A common misconception among beginner developers is assuming that because a JWT looks like an unreadable jumble of letters and numbers, it is safely encrypted.
In reality, the payload is simply Base64URL encoded. Anyone who intercepts the token can decode it in 1 millisecond using native browser tools. The signature verifies authenticity and integrity (proving the server created it and nobody altered the data), but provides zero confidentiality for the payload content.
Standard Registered JWT Claims Explained
| Claim Key | Full Name | Description |
|---|---|---|
| sub | Subject | Unique identifier for the user (usually a database UUID or user ID). |
| exp | Expiration Time | Unix timestamp after which the token must be rejected. |
| iat | Issued At | Unix timestamp recording the exact second the token was created. |
| iss | Issuer | The identity authority or domain that generated the token (e.g. auth.yourdomain.com). |
| aud | Audience | The intended recipient or API service that should consume this token. |
Frequently Asked Questions
Is it safe to paste production tokens into this decoder?
Yes. Unlike other web tools that send tokens across network requests to external servers, our decoder splits and parses Base64 strings entirely inside your local browser memory.
Can this tool verify the signature of my token?
Yes, if you enter your public key or HMAC secret key into the verification box, the tool will verify cryptographic integrity locally using Web Crypto APIs.
Why does my expiration date show as invalid?
In standard JWT specification, `exp` must be expressed in seconds since the Unix epoch (January 1, 1970). If your backend mistakenly sends milliseconds (multiplying by 1000), the date will appear hundreds of years in the future.