What is a JWT? A practical guide for developers in 2026

# The 30-second answer

A JSON Web Token (JWT) is a compact, URL-safe string that lets two parties exchange signed claims. You'll see them everywhere modern auth lives: API access tokens, OAuth flows, password-reset links, server-to-server calls.

A JWT has three parts separated by dots:

xxxxx.yyyyy.zzzzz
header.payload.signature

The header and payload are just Base64URL-encoded JSON. The signature proves the token wasn't tampered with.

<div class="callout callout-note" role="note"><div class="callout-title">Note</div><div class="callout-body"><p>JWTs are <strong>signed</strong>, not <strong>encrypted</strong> by default. Anyone with the token can read the claims. If you need confidentiality, use JWE or encrypt the claims before signing.</p></div></div>

# Anatomy of a token

The header declares the signing algorithm:

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

The payload is your claims — anything you want to assert about the bearer:

{ "sub": "user_123", "role": "admin", "exp": 1735689600 }

The signature is computed from the header + payload + a secret (or private key). If anyone changes a single byte of the payload, the signature stops matching.

# When to use JWTs

• Stateless API authentication — no session lookup on every request.
• Single-sign-on across multiple services that share a public key.
• Short-lived access tokens paired with long-lived refresh tokens.

# When not to use them

• As a session store you want to invalidate. You can't un-issue a JWT short of rotating keys.
• For storing sensitive data — the payload is base64, not encrypted. Anyone can read it.
• As CSRF protection on its own.

# Inspecting a token safely

The safest way to inspect a JWT is in your browser, never paste it into a server you don't control. Our JWT Decoder runs entirely client-side — your token never leaves your device.

If the token came from a public source (a sample, a doc, a test fixture), you can paste it freely. If it's a real production token, treat it like a password.

# Common pitfalls

• Trusting alg: none — always pin the expected algorithm server-side.
• Long-lived tokens — keep access tokens under 15 minutes; use refresh tokens for the long tail.
• Storing in localStorage — vulnerable to XSS. Prefer httpOnly cookies for browser apps.

<div class="callout callout-warning" role="note"><div class="callout-title">Warning</div><div class="callout-body"><p>If your application accepts tokens from user input (e.g. magic-link query params), validate the signature <strong>before</strong> reading any claim. "Decode then verify" is backwards — the right order is "verify then decode."</p></div></div>

# Related tools

• JWT Decoder — inspect a token in your browser
• Base64 Encode/Decode — peek at the parts manually
• Hash Generator — for the curious about HMAC signatures