JSON Stringify and Unstringify
Escape JSON into a string, or peel every layer of escaping off a log payload. Handles double and triple escaping.
Read a JSON Web Token's header and payload with every claim explained and the expiry counted down live.
Decode a JSON Web Token, understand every claim, and see immediately whether anything is wrong with it. Your token stays in this browser.
—
—
Decoding is not validating. The payload above is base64, not encryption — anyone holding this token can read it. Verification with a public key happens here in your browser and proves the token was signed by the matching private key. It does not check whether the token has been revoked, and it cannot be done at all for HS256, which needs the signing secret. That one belongs on your server.
processed in your browser · never uploaded
Straight from your Authorization header, a cookie or a log. The Bearer prefix is stripped automatically.
The payload is shown claim by claim with each abbreviation explained and the timestamps converted to your local time. Switch to Raw for the plain JSON.
The banner counts down how long the token has left. Anything unusual - an unsigned token, a not-yet-valid token, a clock ahead of yours - is called out above the panels.
Decoding shows what a token claims. Only your server, holding the issuer's key, can confirm the signature is genuine.
| Input | Output | Typical saving | Best for |
|---|---|---|---|
| JWT (three parts) | Header, claims, expiry | Reads what the token says | Debugging auth and sessions |
| Authorization header | Same, prefix stripped | Paste as-is | Copying straight from DevTools |
| JWE (five parts) | Explained, not decoded | Encrypted - needs the key | Knowing why it will not open |
We ran the same files through the popular alternatives first. These are the gaps we found, and what this tool does instead.
Verify with a public key only, in your browser. HS256 is refused outright, with the reason given, and a pasted private key is detected and blocked.
test: Paste an HS256 token. The verify button is disabled and says it needs a secret, so verify on your server. Paste a private key against an RS256 token and it is rejected before any verification is attempted.Show each as a local datetime, plus a live countdown of how much time the token has left.
test: Press Sample. The countdown ticks down in real time and turns amber under five minutes.Flag it as an unsigned token and explain that a server accepting it is vulnerable. Same for nbf and iat set in the future.
test: Decode any token whose header says "alg":"none". The warning appears above the payload.A JWT decoder splits a JSON Web Token into its three parts and reads the two that are readable. Paste a token and you get the header, the payload with every claim explained, and a live countdown to expiry.
The important thing to understand about a JWT, and the reason this page runs entirely in your browser: the payload is not encrypted. It is base64, an encoding, not a cipher. Anyone holding the token can read everything inside it with no key at all – which is what this tool is doing. The signature does not hide the contents; it only proves they have not been altered.
That has a direct consequence. A JWT is a live credential, usually a working session. If you paste one into a tool that sends it to a server, you have handed someone a valid login for as long as the token lasts. This tool has no server to send it to.
Header declares the signing algorithm and, often, a kid naming which key was used.
Payload carries the claims – who issued the token, who it is about, what it is allowed to do, and when it stops being valid.
Signature is the part that cannot be read. It is a cryptographic hash of the first two parts, made with a key only the issuer holds.
The tool colours all three so you can see where each one starts and ends, which is usually the first confusing thing about a token.
Registered claims are three-letter abbreviations that are easy to misread. Each one is labelled: iss is the issuer, sub is the subject the token is about, aud is the audience it was minted for, jti is a unique ID used to stop a token being replayed.
The three time claims – exp, nbf and iat – are stored as Unix seconds, which is unreadable at a glance and easy to mistake for milliseconds. Each is shown as a local datetime alongside the raw number.
Expiry, counted down live. Not just the timestamp, but how long is actually left, updating each second and turning amber under five minutes.
alg set to none. This means the token is unsigned. Anyone can change the payload and it will still parse. A server that accepts such a token is vulnerable, and this is a real class of authentication bypass rather than a theoretical one.
nbf in the future. The token is not valid yet. From an application’s point of view this looks exactly like a broken token, and it is easy to spend an hour on it without knowing the claim exists.
iat in the future. The issuing server’s clock is ahead. This causes intermittent rejections that are very hard to reproduce.
It also flags a payload containing anything password-shaped, since a JWT is the wrong place to put a secret that anyone holding the token can read.
Decoding shows what a token says. It does not prove the token is genuine. A token that decodes perfectly may still have been forged, so the panel reads “signature not verified” until you verify it.
You can verify it here, with one deliberate limit.
Tokens signed with RS256, PS256, ES256 and their siblings are verified with the issuer’s public key, which is meant to be public – published at a JWKS endpoint, printed in documentation, safe to hand out. Paste it and the check runs in your browser through the Web Crypto API. Nothing is uploaded, and the result tells you whether this exact token was signed by the matching private key and has not been altered since.
Tokens signed with HS256 and its siblings cannot be verified here, and that is on purpose. HMAC uses one shared secret to both sign and verify, so checking an HS256 signature means handing over the secret that protects your entire authentication system. Plenty of tools will ask you for it. We will not. Verify those on your server, with a library, using a key your server already holds.
If you paste a private key by mistake, the tool spots it and refuses before attempting anything.
Two things verification still does not tell you: whether the token has been revoked, and whether your server would accept it – your server has its own rules about issuer, audience and clock tolerance.
Last reviewed August 2026 · this tool runs on-device.
Paste it and the header and payload are decoded in your browser. Both are base64, not encryption, so no key is needed to read them.
Only if it never leaves your machine. A JWT is usually a live session - pasting one into a tool that uploads it hands over a working login. This tool has no server to upload to.
No. Verifying needs the issuer's secret or public key, which should never be pasted into a web page. Verify on your server with a library.
No. It is base64-encoded, which is why this page can read it without any key. Never put a secret in a JWT payload.
The moment the token stops being valid, stored as Unix seconds. The tool shows it as a local datetime and counts down how long is left.
Check the nbf claim. If it is in the future the token is not valid yet, which looks identical to a broken token from the application's side.
The token is unsigned, so anyone can alter the payload and it will still parse. A server that accepts such a token has an authentication bypass.
The clock on the issuing server is ahead of yours. It causes intermittent, hard-to-reproduce rejections, so the tool flags it.
Escape JSON into a string, or peel every layer of escaping off a log payload. Handles double and triple escaping.
Minify JSON, beautify it back, and see the real compressed size. Flags duplicate keys your parser silently drops.