What a JWT is
A JWT (JSON Web Token) is a compact way to carry information between two parties so that its authenticity can be checked. It’s everywhere in authentication: when you log into an app, the server usually hands your browser a JWT, which is then sent with every request to prove who you are.
Every JWT has three parts separated by dots: header.payload.signature. Each part is text encoded with Base64url (a URL-safe flavour of Base64). This decoder splits the token on the dots, decodes the header and payload, and shows them as readable JSON, all inside your browser.
How to use the decoder
- Copy the full JWT from your app, the browser console, or an
Authorizationheader. - Paste it into the field above. Decoding happens instantly.
- Read the payload (the data) and the header as formatted JSON.
- If the token carries dates (
iat,exp,nbf), each one is shown as a human-readable date, along with a badge telling you whether the token is valid or expired. - Hit Copy to grab the payload or header JSON.
The three parts of a JWT
- Header: names the signing algorithm (
alg, for exampleHS256) and the type (typ, usuallyJWT). - Payload: holds the claims, the actual data. Some are standard (
sub,iat,exp,nbf,iss,aud); others are defined by your app. - Signature: the result of signing the header and payload with a key. It proves the token wasn’t tampered with, but unlike the other two you can’t simply read it; checking it requires the key.
Time fields are stored as epoch values (seconds since 1 January 1970 UTC). To get a real date you multiply by 1000 and convert to a date object.
Worked example
Take this sample token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cIts decoded header is:
{ "alg": "HS256", "typ": "JWT" }And the payload:
{ "sub": "1234567890", "name": "Ada Lovelace", "iat": 1516239022, "exp": 1516242622 }The iat field is 1516239022; multiply it by 1000 and convert, and you get 18 January 2018, 01:30:22 UTC. The exp is 1516242622, exactly 3600 seconds (one hour) later: 18 January 2018, 02:30:22 UTC. Since that moment is already in the past, the decoder flags the token as expired.
Common claims
| Claim | Meaning | Example |
|---|---|---|
iss | Token issuer | my-server |
sub | Subject (user) | 1234567890 |
iat | Issued at (epoch) | 1516239022 |
exp | Expires at (epoch) | 1516242622 |
nbf | Not valid before (epoch) | 1516239022 |
Frequently asked questions
Is it safe to paste my token here?
Yes. Everything runs in your browser with JavaScript; the token is never sent to any server. Even so, avoid sharing live production tokens in public tools or screenshots: until they expire, they grant access to your account.
Why can I see my data without the key?
Because Base64url is not encryption, just a way to represent text. Anyone holding the token can read the header and payload. That’s why you must never put passwords or secrets inside a JWT: doing so is like writing them on a postcard.
How do I verify the signature?
Verification needs the secret key (for HS256) or the public key (for RS256) that the issuer used, and it’s done on the server with a JWT library. This decoder only reads the contents: decoding and verifying are two different things.
What’s the difference between decoding and verifying?
Decoding turns the Base64url back into JSON so you can read it. Verifying uses the key to confirm the signature is valid and the token hasn’t been altered or expired. Trusting a token without verifying its signature is a security mistake.