Decoding, which is not the same as verifying
Decode a JSON Web Token to inspect its header, claims and expiry. Runs entirely in your browser, so tokens are never transmitted.
A JWT is three Base64URL segments separated by dots: header, payload and signature. The first two are merely encoded, so anyone holding the token can read every claim inside it.
This decodes and does not verify. Checking the signature needs the secret or public key, so a decoded token tells you what it claims, never whether those claims are trustworthy.
What this calculator shows
- Header and payload as formatted JSON
- The signing algorithm declared in the header
- Issued-at and expiry timestamps as readable dates, with expiry status
What to keep in mind
- Decoding only — the signature is not verified, which requires a key.
- Runs locally in your browser; the token is not sent anywhere.
FAQs
Is the payload of a JWT encrypted?
No. It is Base64-encoded, which is trivially reversible. Treat every claim as public and never store secrets in a token.
What is the difference between decoding and verifying?
Decoding reads the content and needs no key. Verifying checks the signature against a secret or public key and is the only thing that proves the token was not tampered with.
What do exp and iat mean?
Unix timestamps for expiry and issue time. A token past its exp should be rejected by the server, regardless of how valid the signature is.
Is it safe to paste a real token here?
The decoding happens in your browser and nothing is sent to a server. Even so, a live token is a credential — treat it with the caution you would give a password.
Worked example
What sits inside a token
Input: A standard three-part JWT
Output: Header with alg and typ, payload with sub, name and iat
Note: Everything in the payload is readable by anyone who intercepts the token — which is why passwords and secrets must never go in there.