A JSON Web Token looks like a wall of random characters, but it is just three pieces of encoded JSON. This guide explains what each piece holds, how to read the standard claims, and the crucial difference between decoding a token (safe, what this tool does) and verifying it (needs a secret, what a server does).
The three parts of a token
Split a JWT on its dots and you get header.payload.signature. The header is a tiny JSON object describing how the token was signed — its alg (algorithm) and typ (type). The payload is the interesting part: a JSON object of claims describing who the token is about and how long it is good for. The signature is a cryptographic checksum over the first two parts.
The header and payload are only encoded, not encrypted. Base64url is reversible by anyone, which is exactly why a decoder like this one can show you the contents without any password.
Standard claims you'll see most
The JWT spec reserves a handful of short claim names. iss is the issuer, sub the subject (usually a user id), and aud the intended audience. Three are timestamps: iat (issued at), exp (expires), and nbf (not before). They are stored as seconds since 1970, which is why a raw token shows a big number like 1717000000 instead of a date — this tool converts them for you and tells you whether the window is still open.
Everything else is a custom claim: roles, scopes, tenant ids, feature flags. They are perfectly valid; they just are not defined by the standard, so the Claims Table marks them custom.
Signed is not encrypted
A normal JWT (a JWS) is signed. The signature means a server can detect if anyone altered the header or payload — but it does nothing to hide them. Treat the payload as public: never put passwords, card numbers, or secrets in it. If the contents themselves must be secret, you need an encrypted token (a JWE), which has five segments and cannot be read without the decryption key.
Why decoding is safe but verifying isn't
Reading a token needs nothing but the token, so doing it in your browser is private and harmless. Verifying is a different job: it proves the token is authentic and unexpired, and it requires the issuer's HMAC secret (for HS256) or public key (for RS256/ES256). A browser cannot hold those safely, and a server should never trust a token it has not verified itself. That is why this tool deliberately stops at decoding — and why you should never paste a live production token you do not control, since whoever holds a valid token can usually act as you.