Understanding JSON Web Tokens (JWT)

← All guides

By Bhushan Kumar Singh · Updated October 16, 2026 · 8 min read

JSON Web Tokens (JWTs) are the backbone of authentication in most modern web APIs, yet they are widely misunderstood — which is exactly how they end up misused. This guide explains how a JWT is structured, what its claims mean, and the security pitfalls that matter. You can inspect any token as you read with the JWT decoder.

The three parts

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   // header
.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFkYSJ9  // payload
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV...  // signature

• The header declares the token type and the signing algorithm (e.g. HS256, RS256).
• The payload holds the claims — the actual data.
• The signature is computed over the first two parts with a secret or private key, letting a server verify the token has not been tampered with.

Encoded, not encrypted

This is the single most important thing to understand: a standard JWT is signed, not encrypted. Anyone holding the token can base64-decode the payload and read every claim. The signature guarantees integrity (nobody changed it) but not confidentiality. Never put secrets or sensitive personal data in a JWT payload.

The standard claims

• sub — subject, usually the user id the token represents.
• iss — issuer, who created the token.
• aud — audience, who the token is intended for.
• exp — expiry time (a Unix timestamp); after this the token is invalid.
• iat — issued-at time.
• nbf — not-before time; the token is not valid until this instant.

The time claims are Unix timestamps. To read them in a human form, paste them into the timestamp converter — or let the JWT decoder render them for you.

How verification works

When a request arrives, the server recomputes the signature over the header and payload using its key and checks it matches the token's signature, then confirms the token has not expired and that iss/aud are what it expects. Only then does it trust the claims. Decoding alone — what a browser tool does — is notverification.

Common mistakes to avoid

• Trusting an unverified token. Decoding the payload client-side proves nothing; authorization must verify the signature server-side.
• Accepting alg: none. A classic attack strips the signature and sets the algorithm to none. Reject it.
• Storing secrets in the payload. It is readable by anyone with the token.
• Long or no expiry. Without a short exp, a stolen token stays useful indefinitely. Use short lifetimes plus refresh tokens.
• Treating a JWT like a session you can revoke. A signed token is valid until it expires; build a revocation list if you need to kill tokens early.

Frequently asked questions

Can I read a JWT without the secret key?

Yes — the header and payload are only base64-encoded, so anyone can decode and read them. You need the key only to verify or create a token, not to read it.

Is it safe to paste a JWT into an online decoder?

Only into one that decodes locally. The JWT decoder runs in your browser and uploads nothing. Still, remember a real token is a live credential — inspect test tokens where you can.

What is the difference between a JWT and a session cookie?

A session cookie is an opaque id the server looks up in its store; a JWT carries its data with it and is validated by signature. JWTs scale well across services but are harder to revoke before expiry.

Related

See redacting sensitive data in JSON before sharing payloads that contain tokens, and the timestamp converter for reading exp and iat.

Keep reading

Ready to put this into practice? Open the free JSON editor →