What is a JWT?
A JSON Web Token (JWT, pronounced "jot") is a compact, self-contained way to carry a set of claims — statements like "this is user 1234", "this session expires at 17:00", "this token may read but not write" — between two systems. It is the token format behind most modern login sessions and OAuth2/OIDC flows: you receive one after signing in, your browser or app attaches it to API requests, and the API reads the claims to decide who you are and what you may do, without a database lookup per request. The whole token is one string of three Base64URL-encoded parts joined by dots, short enough to travel in an HTTP header — and, famously, readable by anyone who holds it.
Decode is not verify — read this first
Two operations are constantly confused, and the confusion has caused real breaches. Decoding is just unwrapping: Base64URL is an encoding, not encryption, so the header and payload of any JWT can be read by anyone, including you on this page. Verifying is the security operation: checking that the signature was produced by a trusted issuer's key over exactly these header and payload bytes, that the algorithm is one you accept, and that the token has not expired. This tool performs the first operation and never the second — it has no keys and no opinion about trust. A beautifully formatted, perfectly decodable token can be completely forged. If you are debugging your own system, decode here to see what a token says; let your server decide whether to believe it.
How to use this tool
- Paste the token (a leading
Beareris stripped automatically). - Press Decode. You get the header and payload as formatted JSON, every payload claim translated into a table with its meaning, and the raw signature segment.
- Read the warnings first if any appear: expired token,
alg: none, an empty signature, or a missingexp— the four things most often wrong with a token in the wild. - Time claims (
exp,iat,nbf) are shown both as raw NumericDates and as ISO timestamps, so "is it expired?" answers itself.
The three parts, and the claims that matter
The header is metadata about the token itself:
alg names the signing algorithm, typ is
usually JWT, and kid identifies which of the
issuer's keys signed it — the field key rotation hangs off. The
payload carries the claims. The registered names are
worth knowing cold: iss (issuer), sub
(subject — usually the user id), aud (audience — who may
accept this token), exp, iat and
nbf (the time claims), and jti (a unique id
used for revocation lists). Everything else in the payload is a private
claim added by the issuer — roles, tenant ids, feature flags. The
signature is computed over the first two segments
exactly as transmitted, which is why editing one character of the
payload — changing a role, extending an expiry — invalidates it.
Our background guide, What is a JWT?,
walks through how tokens are issued, signed and checked in a real
login flow, including the algorithm-confusion attacks that made
alg: none infamous.