JSONBench

JWT decoder

Header, claims and expiry as readable dates. Decoded in this tab — and decoding is not verification.

Network measuring… Your data never leaves this tab
Decoded, not verified. The header and payload of a JWT are base64url — not encrypted, not secret, readable by anyone who has the token. What makes a token trustworthy is its signature, and checking that requires the signing key. This page does not have it, will never ask for it, and therefore cannot tell you whether a token is genuine.

Why that distinction matters

It would be easy to put a green tick next to a token that decodes cleanly. It would also be actively harmful: a developer who reads that as "valid" may skip signature verification on the server, and a JWT whose signature is not checked is simply a claim the client made about itself. Anyone can mint one asserting any role they like.

Several decoders blur this line. The rule is simple — decoding happens anywhere, verification happens on your server with the key, on every request, every time.

Reading the claims

The header names the signing algorithm. alg: none means unsigned, and historically some libraries accepted such tokens as trusted — if you see it where a signature is expected, treat it as a security finding.

In the payload, exp, iat and nbf are Unix timestamps in seconds. They are rendered here as local dates with the time remaining, because expiry bugs are usually caused by someone comparing ten-digit numbers by eye, or by seconds being confused with the milliseconds JavaScript uses everywhere else.

The rest of the bench

Base64The encoding underneath a JWTJSON formatterFor the decoded payloadPassword toolsAlso entirely local

Questions

Does this verify the signature?
No, and no browser page can without the secret or public key — which you should never paste into a website. This decodes the header and payload, which are only base64url-encoded and were never secret. Decoding tells you what a token claims. It tells you nothing about whether those claims are authentic.
So what is the signature for?
It is what makes the claims trustworthy. Anyone can craft a token that says they are an administrator; only the holder of the signing key can produce a matching signature. This is why verification must happen on your server, with the key, on every request — and why a token that merely decodes cleanly proves nothing.
Is it safe to paste a real token here?
The page makes no network request, so nothing is transmitted — you can verify that in the Network tab. That said, a JWT is a live credential until it expires: treat pasting one anywhere with the same caution as a password. If the token is in use, the careful habit is to decode an expired one.
What does alg: none mean?
It means the token is unsigned, and it is a genuine attack: some libraries historically accepted a token with the algorithm switched to none and no signature, trusting it completely. If you see it on a token that should be signed, that is a finding worth chasing, not a curiosity.
What are exp, iat and nbf?
Unix timestamps in seconds. exp is when the token expires, iat when it was issued, nbf the earliest moment it may be accepted. They are shown here as readable dates because comparing ten-digit integers by eye is how expiry bugs get missed.