What Is a JWT? A Practical Guide

If you've worked with modern web APIs, you've run into a JWT — a long string starting with eyJ tucked into an Authorization header or a cookie. Here's what it actually is, how it's built, and what to watch out for.

The short definition

A JWT (JSON Web Token), defined in RFC 7519, is a compact way to represent a set of claims — statements about a user or entity — as a signed, URL-safe string. Servers issue them (typically after login) so that subsequent requests can prove who the caller is without the server having to look anything up in a database.

Anatomy of a JWT

A JWT is three Base64URL-encoded segments joined by dots: header.payload.signature.

• Header — a small JSON object naming the signing algorithm and token type, e.g. {"alg":"HS256","typ":"JWT"}.
• Payload — the actual claims, e.g. {"sub":"1234","exp":1735689600}.
• Signature — a cryptographic signature over the header and payload, computed with a secret (HMAC) or private key (RSA/ECDSA), that lets the server detect if the token was tampered with.

Each of the first two segments is just JSON run through Base64URL encoding — the same encoding our Base64 Decode tool handles, with the URL-safe alphabet (-/_ instead of +//). That's an important distinction: encoding is not encryption. Anyone can decode a JWT's header and payload without any key at all — try pasting one into our JWT Decoder and watch it happen instantly, entirely in your browser.

Common claims you'll see

RFC 7519 defines a handful of standard (but optional) claims:

• iss — issuer, who created the token.
• sub — subject, usually the user ID.
• aud — audience, who the token is intended for.
• exp — expiration time (Unix timestamp).
• iat — issued-at time.
• nbf — not-before time; the token isn't valid until this instant.

Everything else in the payload is typically application-specific — roles, permissions, session metadata.

How JWTs get signed

The signature is what makes a JWT trustworthy, and there are two broad families of algorithm:

• Symmetric (HS256, HS384, HS512) — a single shared secret both signs and verifies the token. Simple, but every service that verifies tokens must hold that same secret, which is a real key-management risk if it leaks. Under the hood this is just HMAC, the same hashing primitive our Hash Generator demonstrates.
• Asymmetric (RS256, ES256, and friends) — a private key signs, a public key verifies. The issuer keeps the private key secret; any service can safely hold the public key to verify tokens without being able to forge new ones. This is the safer default for systems with multiple services verifying tokens issued by one auth server.

JWTs vs. session cookies

Traditional session auth stores a session ID in a cookie and keeps the actual session data server-side (often in a database or Redis). JWTs flip that: the data travels with the token itself, so any service holding the verification key can validate a request without a round-trip to a shared session store. That statelessness is why JWTs are popular for APIs and microservices — but it comes with a real tradeoff: you can't easily revoke a single JWT before it expires. With a server-side session, deleting the session row instantly logs the user out everywhere; with a JWT, the token stays valid until its exp claim passes, unless you build a separate revocation/blocklist mechanism.

Common mistakes worth avoiding

• Putting sensitive data in the payload. Passwords, secrets, or anything confidential don't belong there — the payload is trivially readable by anyone who has the token.
• Not verifying the signature server-side. Decoding a JWT to read its claims is not the same as verifying it came from a trusted issuer and wasn't tampered with. Always verify before trusting the contents.
• Accepting alg: none. A handful of historical library bugs let attackers submit an unsigned token with the algorithm set to none and have it accepted as valid. Reject it explicitly.
• Long-lived tokens with no revocation plan. The longer the expiry, the longer a stolen token stays useful to an attacker.

Try it yourself

Paste any JWT into our JWT Decoder to see the header and payload broken down, with expiration status highlighted automatically. Like every tool on this site, decoding happens entirely in your browser — your token is never sent anywhere.