Both segments decoded instantly
The Base64URL header and payload are unpacked into readable, indented JSON as soon as you paste, with no round trip to a server.
JWT Decoder & Inspector
Decode a JSON Web Token's header and payload and read its claims.
- Input
- No upload needed — instant
- Privacy
- Nothing is uploaded
- Cost
- Free · no sign-up · no watermark
Loading tool…
The tool is loading its code on your device. This happens once and is cached for later visits.
Processed entirely on your device
Everything you type or paste is handled by JavaScript running in this tab. No request is sent, nothing is logged and nothing is stored. Close the page and it is gone.
Overview
About the JWT Decoder & Inspector
Decode and inspect JSON Web Tokens online. View the header and payload as formatted JSON, read the exp, nbf and iat claims and check expiry — no verification, no upload.
A JSON Web Token is three Base64URL-encoded sections joined by dots: a header, a payload and a signature. The first two are ordinary JSON that has been encoded so it survives inside a URL, an HTTP header or a form field. Reading them needs no secret, which is what makes this tool possible and also what makes the most important warning about JWTs so easy to forget.
The three parts
Base64URL is standard Base64 with plus and slash replaced by hyphen and underscore and the padding removed, so the token is safe in a URL. Encoding is not encryption. Anyone holding a token can decode and read every claim, so a JWT payload is effectively public to whoever receives it.
Decoding is not verifying
This tool unpacks the header and payload and shows them to you. It does not check the signature, because that requires the issuer's secret or public key, which your browser does not have and should not want. A token can be perfectly readable and completely forged. The only component entitled to trust a JWT is the one that verifies the signature with the correct key, and that check belongs on the server, never in client-side code alone.
The claims that matter
Standard claims use short registered names:
- iss — the issuer that created the token
- sub — the subject, usually a user identifier
- aud — the audience the token is intended for
- exp — expiry, a Unix timestamp after which the token must be rejected
- nbf — not before, a timestamp before which it is not yet valid
- iat — issued at, the moment the token was created
The exp, nbf and iat values are integers counting seconds since the Unix epoch, so this tool converts them to readable dates and tells you whether the token is currently expired, not yet valid, or inside its window.
The algorithm-none trap
Because the header states which algorithm signed the token, a naive verifier that believes that field can be tricked by an attacker who sets the algorithm to none and drops the signature entirely. Serious libraries reject an unverified or downgraded algorithm and make you declare which algorithms you accept. It is a neat illustration of the whole subject: reading a token and trusting a token are two completely different operations, and only the second one is a security decision.
Step by step
How to use the JWT Decoder & Inspector
Paste a JWT into the input panel; a leading Bearer prefix is stripped automatically.
Read the decoded header and payload as formatted JSON.
Check the time claims to see whether the token is expired or not yet valid.
Remember the signature is shown but never verified — that needs the issuer's key.
Why use it
Benefits and common use cases
What this tool is good for, and what it deliberately does not try to do.
Expiry made obvious
The exp, nbf and iat numeric dates are converted to real timestamps and checked against the current clock, so you can see at a glance whether a token is still valid.
Honest about verification
The signature is displayed but clearly labelled as unchecked, because a decoder that implied validation would be a security trap.
Tokens stay local
Access tokens carry user identifiers and scopes. Decoding happens in your tab, so a live token is never pasted into someone else's infrastructure.
Questions
Frequently asked questions
Short, honest answers about quality, limits and privacy.
Does decoding a JWT verify its signature?
No, and no browser-side decoder honestly can without the issuer's key. Decoding only reverses the Base64URL encoding of the header and payload. Anyone can produce a token with any claims they like; only a valid signature from the right key makes those claims trustworthy.
Is the payload encrypted?
No. A standard JWT payload is Base64URL-encoded, not encrypted, so anyone holding the token can read every claim in it. Never place a password, a secret or sensitive personal data in a JWT payload. Encrypted payloads require JWE, which is a different format.
What do the standard claims mean?
iss is the issuer, sub is the subject or user id, aud is the intended audience, exp is the expiry timestamp, nbf is the not-before time and iat is when the token was issued. The exp, nbf and iat values are numbers counting seconds since the Unix epoch.
Why is my valid-looking token being rejected?
Usually one of three things: the exp claim has passed, the signature does not match the key the server expects, or the algorithm in the header is not one the server accepts. This tool shows you the first and hints at the third; only the server can check the second.
What is the alg none attack?
The header declares which algorithm signed the token. A poorly written verifier that trusts that field can be fooled by an attacker who sets the algorithm to none and removes the signature. Correct libraries require an allow-list of algorithms and reject downgrades.