JWT Decoder — Read Token Header & Payload
Decode a JWT to clearly read its header and payload, instantly and privately in your browser.
The token stays on your device
Nothing to delete afterwards
Built for live credentials
Works in every modern browser
How it works
- 1
Paste the token
The whole thing, including both dots — the three parts are separated by them.
- 2
Read the claims
Header on one side, payload on the other, with timestamps converted to dates.
- 3
Check what you came for
Usually the expiry, the issuer, the audience, or which user the token is actually for.
Why use this tool
Header and payload side by side
The algorithm and key hint next to the claims, which is where most debugging questions are answered.
Timestamps in readable form
`exp`, `iat`, and `nbf` shown as dates rather than as ten-digit numbers you have to convert.
Expiry checked against now
You see immediately whether the token is still within its window, without doing the arithmetic.
Honest about verification
This decodes; it does not verify a signature, and it says so rather than implying the token is valid.
Nothing is transmitted
The token is parsed in your browser — a working session credential never reaches a server.
Free, no account
No signup, no watermark, no cap on how many tokens you inspect.
Decoding is not verifying, and the difference is the entire security model
A JWT has three parts separated by dots, and the first two are simply base64url text. Anyone holding the token can read the header and the payload in one step — that is what this page does, and it requires no key, no permission, and no secret. Verification is a completely separate operation: recomputing the signature over the first two parts using the issuer's key and checking that it matches the third. Only verification tells you the token is authentic and unmodified. A decoder tells you what a token claims, never whether the claim is true, because anyone can craft a token that says whatever they like. If you are debugging, decoding answers your question. If you are deciding whether to trust a request, decoding answers nothing at all.
The payload is readable by anyone, and people forget that constantly
This follows from the above and deserves stating on its own, because it is the source of real data exposure. A JWT payload is encoded, not encrypted. Every claim in it — the user identifier, the email address, the role, the tenant, whatever internal fields were convenient to include — is visible to anyone who has the token, including the browser it was issued to, any extension running in that browser, and anyone who obtains it later. The signature protects the payload from being changed, not from being read. So a token is a reasonable place for an identifier and a role, and a poor place for an address, a phone number, a licence status somebody might find embarrassing, or anything else you would not print on the outside of an envelope. If a claim needs to stay private, it does not belong in the token.
Never let the token tell you how to verify itself
The most famous JWT vulnerabilities all share one shape: a library reads the `alg` field from the header and trusts it. The historic version is `alg: none`, which declares the token unsigned — a verifier that honours it accepts anything, and an attacker simply writes their own payload and strips the signature. The subtler version is algorithm confusion, where a token signed with HMAC is presented to a server expecting RSA; if the code passes the RSA public key in as the HMAC secret, and that public key is published, the attacker can sign tokens with it. Both are fixed the same way: the verifying code decides which algorithm and which key it will accept, and rejects everything else, rather than reading the answer out of the untrusted part of the token it is checking.
The timestamps are seconds, and nothing enforces them by itself
Three claims control the window a token is valid in. `exp` is the expiry, `nbf` is the time before which it must not be accepted, and `iat` is when it was issued. All three are seconds since the Unix epoch, which trips up anyone working in a language whose native timestamps are milliseconds — the resulting token is either already expired or valid for the next fifty thousand years, and both mistakes are common enough to check for first. The more important point is that these are claims, not enforcement. Nothing about a token stops working when `exp` passes; expiry only exists if the verifying code compares it against the current time and rejects the request. A decoder showing you an expired token tells you what the issuer intended, not what any particular server will do with it.
A JWT cannot be revoked, and that is the deal you accepted
The reason to use these tokens is stateless verification: a server can confirm a request is authentic using only a key, without a database lookup, which is what makes them scale across services. The direct consequence is that there is nothing to delete. A session stored in a database ends the moment you remove the row; a signed token remains valid until its expiry no matter what happens at the issuer, because nothing consults the issuer. A leaked token is therefore usable until it expires, which is precisely why access tokens should have short lifetimes — minutes, not weeks — with a longer-lived refresh token that can be revoked because it *is* checked against storage. If your access tokens last a month, you have all the drawbacks of statelessness and none of the safety of sessions.
Why this is the sharpest case for decoding locally
Almost every other text tool handles material that is sensitive by circumstance. A JWT is sensitive by definition: it is the credential, and a valid unexpired token is enough to act as the user it was issued to. Pasting one into a hosted decoder sends a working authentication credential to a third party, over a channel that leaves no trace, in exchange for reading fields you could have read locally. If the token has hours left on it, whoever receives it can use it. This page parses in the browser and transmits nothing, which you can confirm in the Network tab of your developer tools — and if you have ever pasted a production token into a website to check its expiry, treating that token as compromised is the correct response.
Common mistakes to avoid
- Treating a successful decode as a valid token. Decoding needs no key and proves nothing; only verifying the signature against the issuer’s key establishes that the token is authentic.
- Putting private data in the payload. It is encoded, not encrypted — the signature stops it being changed, not read, so anyone holding the token sees every claim.
- Letting the token choose its verification algorithm. Reading `alg` from the header is how `alg: none` and algorithm-confusion attacks work; the verifier must fix the algorithm and key in advance.
- Writing `exp` in milliseconds. JWT timestamps are seconds since the epoch, so a millisecond value produces a token valid for tens of thousands of years — or one that is already expired.
- Pasting a production token into a hosted decoder. It is a live credential, the paste leaves no trace, and anyone who receives it can use it until it expires.
How it compares
| Aspect | This tool | Online decoders | A library call |
|---|---|---|---|
| Token sent to a server | Never | Usually yes | No |
| Timestamps shown as dates | Yes | Sometimes | You format them |
| Clear that it does not verify | Yes | Often unclear | Explicit in the API |
| Works without a project open | Yes | Yes | No |
| Account or signup | Not needed | Often required | Not needed |
| Price | Free | Free / paid tiers | Free |
Features
Full three-part parsing
Header, payload, and the signature segment shown separately as the format defines them.
Base64url handled correctly
JWTs use the URL-safe alphabet without padding, which a plain Base64 decoder gets wrong.
Standard claims labelled
`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, and `jti` are named rather than left as abbreviations.
Malformed tokens flagged
A missing segment or invalid encoding is reported instead of producing partial nonsense.
Unicode in claims preserved
Names and values in Arabic, Turkish, or any script decode intact.
Instant, no request
Parsing happens as you paste, with nothing fetched and nothing sent.
Nothing to install
No library, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no content tracking and no third-party upload.
Who uses it
Developers
Checking why an API call is rejected — usually an expired token or the wrong audience.
Security engineers
Inspecting the claims and algorithm of a token found in a log or a bug report.
API integrators
Confirming which scopes and roles a provider actually issued before writing against them.
Support engineers
Reading a customer-supplied token to see which account and tenant it belongs to.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.