JSON Web Tokens (JWT), Explained

By Udit Agarwal · Updated October 13, 2026

JSON Web Tokens are everywhere in modern authentication — and widely misunderstood. The biggest myth is that a JWT is encrypted and therefore safe to put secrets in. It isn't. This guide breaks down exactly what a JWT contains, what every claim means, how signing works, and where the real security boundary lies.

What is a JWT?

A JWT (JSON Web Token, RFC 7519) is a compact, URL-safe way to represent claims — statements about a subject — that are transferred between two parties. In practice you'll meet them most often as access tokens: after you log in, a server hands your client a JWT, and the client sends it back on every request to prove who it is.

"Compact" and "URL-safe" matter: a JWT is short enough to fit in an HTTP Authorization header and contains only characters that are safe in URLs and cookies.

JWTs are popular because they're stateless. A traditional session stores data on the server and gives the client an opaque id; the server must look that id up on every request. A JWT instead carries the claims inside the token, signed so the server can trust them without a database lookup.

The three parts of a JWT

A JWT is three Base64url-encoded segments joined by dots:

header.payload.signature

For example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWRhIn0.4pcPyMD0...

Each segment decodes to something human-readable. (Note: this is Base64url, a URL-safe variant — +// become -/_ and padding = is dropped.)

1. Header

The header is a small JSON object describing how the token is signed:

{ "alg": "HS256", "typ": "JWT" }

• alg — the signing algorithm (e.g. HS256, RS256).
• typ — the token type, usually JWT.
• kid — an optional key id that tells the verifier which key to use.

2. Payload (the claims)

The payload carries the claims. Several are registered as standard:

You can also add your own custom (private) claims — roles, tenant id, plan — but keep the token small, because it's sent on every request.

3. Signature

The signature is computed over the encoded header and payload using either a shared secret (HMAC, e.g. HS256) or a private key (RSA/ECDSA, e.g. RS256/ES256). It lets a recipient verify two things: that the token hasn't been tampered with, and that it was issued by someone holding the key.

Signing algorithms

Use HMAC when the same trusted service both issues and verifies tokens. Use RSA/ECDSA when many parties need to verify tokens but only one should be able to issue them (e.g. an identity provider publishing a public key).

Decoding vs. verifying — the key distinction

This is the part that trips people up:

• Decoding a JWT just means Base64url-decoding the header and payload. Anyone can do this — no key required. The payload is readable to whoever holds the token.
• Verifying a JWT means recomputing the signature with the key, checking it matches, and confirming exp/nbf/aud/iss. Only this step proves the token is authentic and current.

A JWT is signed, not encrypted. Decode it freely for debugging, but never store passwords, API keys, or other secrets in the payload — anyone with the token can read them. If you genuinely need a confidential payload, use JWE (JSON Web Encryption).

Common pitfalls

• Treating the payload as private. It's just Base64 — assume it's public.
• Accepting alg: none. A token claiming no signature must be rejected. Historically, libraries that honoured alg: none allowed trivial forgery.
• Algorithm confusion. Pin the expected algorithm; don't let a token's own alg header downgrade an RS256 verifier into treating the public key as an HMAC secret.
• Ignoring exp. Always reject expired tokens. Prefer short-lived access tokens plus a refresh token.
• No revocation plan. Because JWTs are stateless, a leaked token is valid until it expires — keep lifetimes short and consider a jti denylist for emergencies.
• Logging full tokens. A leaked token is a leaked session.

JWT vs. session cookies

Neither is universally "better" — JWTs shine for distributed services and APIs; server sessions shine when instant revocation matters.

Decode a JWT online

The JWT Decoder splits a token into its header and payload and shows the exp/iat times in a readable form — without verifying the signature, and without sending the token anywhere. It runs entirely in your browser, so the token never leaves your device.

Frequently asked questions

Is a JWT encrypted? No. It's signed and Base64url-encoded. Anyone can read the payload; the signature only guarantees integrity.

Can I trust a JWT I just decoded? Not on its own. Decoding proves nothing — you must verify the signature and check exp/aud/iss with the issuer's key.

Where should I store a JWT in a browser? Prefer an HttpOnly, Secure cookie to reduce XSS exposure; avoid localStorage for sensitive tokens.

What's the difference between a JWT and an opaque token? A JWT is self-describing and verifiable without a lookup; an opaque token is a random id that only means something to the server that issued it.

Is my token uploaded when I decode it here? No. The JWT Decoder runs entirely in your browser.

Keep going

• JWT Signer — create and sign your own HS256/384/512 tokens.
• Base64 Encoder / Decoder — see what Base64url actually does.
• Hash Generator — SHA hashing with the Web Crypto API.
• TOTP / 2FA Generator — the other half of modern auth.

JWT-Dekoder

More guides

• Cryptographic Hash Functions, Explained — What a cryptographic hash is, how MD5, SHA-1, SHA-256 and SHA-512 compare, how checksums verify downloads, and why fast hashes are wrong for passwords.
• Strong Passwords, Explained — What makes a password strong: length vs complexity, password entropy in bits with worked numbers, passphrases, password managers and current NIST advice.
• Base64 Encoding, Explained — Base64 explained: how it turns binary into text, the alphabet and padding, the URL-safe variant, size overhead, use cases, and why it isn't encryption.
• Linux File Permissions and chmod, Explained — What chmod 755, 644 and 777 mean: owner, group and others, read, write and execute, octal and symbolic modes, umask, setuid, setgid and the sticky bit.
• DMS and Decimal Degrees, Explained — How to convert DMS to decimal degrees and back, how DD, DMS and DDM differ, how many decimal places you need, and which formats Google Maps and GPS accept.
• Date Calculations, Explained: Counting and Adding Days — How to count the days between two dates, add days, weeks or months to a date, and why calculators disagree: inclusive counts, month ends and leap years.

All Security tools · All guides

---