A JSON Web Token (JWT, pronounced "jot") is a compact way to package a set of claims — who a user is, what they're allowed to do, when the token expires — into a single string that can travel in an HTTP header, a URL, or a cookie. You'll see them constantly in modern authentication: log into almost any API-driven app and there's a good chance a JWT is riding along with every request.
The three parts
A JWT is three Base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm and token type. The payload holds the actual claims — often things like sub (subject/user ID), iat (issued-at time), and exp (expiry). The signature is a cryptographic hash of the header and payload, computed with a secret or private key the issuing server holds.
Base64url encoding is not encryption — it's the same kind of reversible text encoding used in data URIs, just with a URL-safe alphabet. Anyone who has the token can decode the header and payload instantly, without needing the signing key at all.
Decoding vs. verifying — the part everyone gets wrong
Decoding a JWT just reveals what it claims. Verifying a JWT checks the signature against the issuer's key to confirm those claims haven't been tampered with. These are completely different operations, and conflating them is a real security bug: if your server trusts a JWT's payload without verifying the signature first, anyone can hand-craft a token claiming to be an admin and your server will believe it.
A JWT decoder (including the one below) intentionally does not verify signatures — it has no access to the issuer's secret key, and showing an unverified "valid" badge would be actively misleading. Signature verification always has to happen server-side, where the key actually lives.
Why expiry matters
The exp claim is a Unix timestamp marking when the token stops being valid. A correctly implemented server rejects an expired token even if its signature checks out — this limits how long a stolen or leaked token stays useful. Short-lived JWTs (minutes to hours) paired with a separate longer-lived refresh token is the standard pattern for balancing security against not forcing users to log in constantly.
Try it
GlaeKit's JWT Decoder parses the header and payload entirely in your browser — nothing is sent to a server, and it never attempts signature verification.
Frequently asked questions
Is a JWT encrypted?
No, not by default. A standard JWT is signed, not encrypted — the header and payload are readable by anyone. There's an encrypted variant (JWE), but it's far less common than the signed JWTs (JWS) most APIs use.
Can I trust the contents of a JWT without checking the signature?
No. Anyone can construct a JWT with any payload they like — trusting it without verification means trusting arbitrary user input. Signature verification is what actually establishes that a token came from the claimed issuer.
Why use a JWT instead of a server-side session?
A JWT is self-contained — the server can verify it without a database lookup, which scales better across multiple servers with no shared session store. The tradeoff is that a JWT can't be instantly revoked before it expires, unlike a server-side session that can be deleted on demand.