JWT decoder
Decode a JSON Web Token's header and payload and check its expiry.
FreeRuns in your browserNo signupUpdated 2026-10-29
Decoding happens in your browser; the token is not sent anywhere. Even so, avoid pasting production tokens into any website you do not control.
Parts
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzhmM2EyYyIsImF1ZCI6Im1zaC1wb3J0YWwiLCJpYXQiOjE3NjE2OTYwMDAsImV4cCI6MTg5MzQ1NjAwMCwicm9sZSI6ImFkbWluIiwiZW1haWwiOiJhc2hhQGV4YW1wbGUuY29tIn0.DE0ZPt_NQHOrFf4-bhohQ0574UQaJ57STCPLcZb4_kY
Red: header. Accent: payload. Green: signature.
Token
Decoded
Algorithm HS256 · JWT
Validity
–
Expiry claim present
Signature
Not verified
Needs the secret or public key; never done here
Claims
| Claim | Value |
|---|---|
| issIssuer | https://auth.example.com |
| subSubject | user_8f3a2c |
| audAudience | msh-portal |
| iatIssued at | 2025-10-29 00:00:00 UTC |
| expExpires | 2030-01-01 00:00:00 UTC |
| role | admin |
| asha@example.com |
{
"alg": "HS256",
"typ": "JWT"
}{
"iss": "https://auth.example.com",
"sub": "user_8f3a2c",
"aud": "msh-portal",
"iat": 1761696000,
"exp": 1893456000,
"role": "admin",
"email": "asha@example.com"
}A decoded token proves nothing about who issued it. Anyone can craft a payload. Only a signature check with the issuer's key confirms it, and that check must happen on the server.
About this tool
How it works and how to read the result.
Need this done for you?
Web app & SaaS development
SaaS products and web apps, from first version to scale.
See the serviceWhat it does
The JWT decoder splits a JSON Web Token into its three Base64URL parts and shows the header and payload as formatted JSON. Standard claims are labelled, and the time claims exp, iat and nbf are converted to UTC dates with a relative time such as "in 3 days" or "2 hours ago". A validity badge tells you whether the token is current, expired or not yet valid. The signature is shown but never verified, because that needs the issuer's key and belongs on the server. A leading "Bearer " from a copied header is stripped automatically.
How to use it
- Copy the token from a request header, a cookie or your auth provider's dashboard.
- Paste it into the box. The coloured parts panel confirms the split into header, payload and signature.
- Read the claims table. Check
iss,audand the dates against what your app expects. - Copy the header or payload JSON if you need it in a test or a bug report.
How to read the result
The example token decodes to an HS256 header and a payload with iss of https://auth.example.com, a sub of user_8f3a2c, an aud of msh-portal, an iat of 1761696000 (29 October 2025) and an exp of 1893456000 (1 January 2030), so the badge reads Current. Change the last digit of exp to make it earlier than today and the badge turns to Expired.
"No expiry" is a warning, not an error: tokens without exp never time out on their own, which is a risk for anything beyond local testing. "Not valid yet" means nbf is in the future, often a clock difference between the issuing server and yours.
An alg of none is a red flag. Servers must reject such tokens, since anyone can create them. If the header's alg does not match what your server expects, that is also worth investigating.
The payload is readable by anyone who holds the token, so it should never carry secrets. Authentication flows like this are standard in our web app development work. To inspect the raw parts, use the Base64 encoder and decoder.
Questions
Frequently asked.
Does this verify the token's signature?
No, and it says so on the page. Verifying needs the issuer's secret or public key and must happen on your server, where the key is kept. A decoder only reads the two JSON parts. A token that decodes cleanly can still be forged, expired or revoked.
Is it safe to paste a real token here?
Decoding runs in your browser and the token is not sent anywhere. Still, a live token grants access to whatever issued it, so treat it like a password: prefer tokens from a test environment, and if you paste a production one, revoke it afterwards.
What are exp, iat and nbf?
They are Unix timestamps in seconds. iat is when the token was issued, nbf is the earliest moment it is valid, and exp is when it stops being valid. Servers compare exp with the current time, usually allowing a minute or so of clock skew.
Your next move
Like what you see? Tell us about it.
A process that takes too long, a website that undersells you, or an idea ready to take shape. Tell us where you are and we will suggest a useful next step.
India · Working with clients worldwide