The Ultimate Guide to JSON Web Tokens (JWT) in 2026

If you've signed into a modern web or mobile app, chances are a JSON Web Token changed hands within the first few milliseconds. JWTs (often pronounced "jot") are the de facto standard for passing identity between two parties — most commonly between the server that authenticates you and every service that afterwards needs to trust that authentication.

This guide walks through what a JWT actually contains, how its three parts fit together, where tokens genuinely shine, and the security practices that separate a solid implementation from a breach waiting to happen.

What a JWT actually is

A JSON Web Token, defined in RFC 7519, is a compact, URL-safe string that carries a set of claims — statements about a user or a system, such as "this is user 1234" or "this token stops being valid at noon". The defining property of a JWT is that it is signed. The issuing server signs the token cryptographically, and any service holding the right key can verify that signature without contacting the issuer again.

That is what makes JWTs "self-contained": the proof of who you are travels inside the token itself. A service receiving one doesn't need to look up a session in a database — it verifies the signature, reads the claims, and moves on. This is exactly why JWTs became the backbone of stateless APIs, single sign-on flows, and microservice architectures.

The three parts of a token

Every JWT is three Base64Url-encoded segments joined by dots, in the shape header.payload.signature. Here is the classic example token with line breaks added at each dot:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decode the first two segments and you get plain, readable JSON:

// Header — how the token is signed
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload — the claims
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

• The header declares the token type and the signing algorithm — HS256 (a shared-secret HMAC) and RS256 (a public/private key pair) are the two you'll meet most often.
• The payload carries the claims: who the token is about, who issued it, and how long it's valid. You can add your own custom claims here too, like roles or permissions.
• The signature is computed over the encoded header and payload. Change so much as one character of either, and the signature check fails — that's what makes a JWT tamper-evident.

The registered claims worth knowing

The spec reserves a handful of short claim names. None are mandatory, but well-built systems use most of them:

Where JWTs are used in practice

• API authentication — the client sends the token in an Authorization: Bearer header, and the API verifies it on every request without a session store.
• Single sign-on — one identity provider issues a token that many separate applications can independently verify and trust.
• Service-to-service calls — microservices pass signed tokens so each hop can prove where a request originated.
• Short-lived action links — password resets and email verification links often embed a JWT with a tight exp claim so the link expires on schedule.

Reading a token is not the same as trusting it

Base64Url is an encoding, not encryption — it's trivially reversible by design. The signature stops anyone from modifying a token, but it does nothing to stop them from reading it.

Security best practices

• Verify the algorithm, not just the signature. Libraries should be configured with an explicit allowlist of accepted algorithms — the infamous "alg": "none" attack worked because servers accepted whatever algorithm the token declared.
• Keep access tokens short-lived. Minutes, not days. Pair them with a refresh token so users aren't forced to log in constantly.
• Always check exp, iss, and aud. A cryptographically valid token can still be expired, minted by the wrong issuer, or intended for a different service.
• Transmit tokens over HTTPS only. A bearer token is exactly what it sounds like — whoever bears it, wins.
• Choose token storage deliberately. An httpOnly, Secure cookie shields the token from XSS but requires CSRF defenses; localStorage is convenient but readable by any script that runs on your page.
• Plan for revocation. Signed tokens can't be recalled once issued, so keep expiry short and use a jti deny-list for the cases where you must cut a token off early.

Decode a token yourself

While you're debugging, the Base64 Encoder / Decoder handles raw segment decoding, and the JSON Formatter pretty-prints any payload you extract.

Frequently asked questions