What Is a JWT Token and How Does It Work?

If you have ever logged into a modern web application, inspected an Authorization: Bearer ... header, or wired up an OAuth login, you have met a JSON Web Token, better known as a JWT (pronounced "jot"). JWTs are the dominant format for carrying identity claims between services, and yet many developers use them daily without being entirely sure what is inside the string. This guide explains what a JWT is, how it is constructed, what the signature actually proves, and where the sharp edges are.

If you want to look inside a token right now, our free JWT Parser & Validator decodes the header and payload, checks expiration claims, and verifies HMAC signatures entirely in your browser — the token never leaves your machine.

The structure of a JWT

A JWT is three Base64URL-encoded segments separated by dots: xxxxx.yyyyy.zzzzz. The first segment is the **header**, the second is the **payload**, and the third is the **signature**. Base64URL is a slight variant of ordinary Base64 that uses - and _ instead of + and / and drops the = padding, so the token survives URLs and HTTP headers without extra escaping.

The header is a small JSON object, typically {"alg": "HS256", "typ": "JWT"}. The alg field declares which algorithm was used to sign the token — common values are HS256 (HMAC with SHA-256), RS256 (RSA signature with SHA-256) and ES256 (ECDSA). The payload is another JSON object containing **claims**: statements about the user and the token itself. Typical claims include sub (subject — the user ID), iss (issuer), aud (audience), iat (issued-at time), nbf (not-valid-before) and exp (expiration time), plus any custom claims your application adds, such as a role or tenant ID.

Crucially, Base64URL is an *encoding*, not encryption. Anyone who gets hold of a token can decode and read the payload in seconds. A JWT keeps no secrets — it proves authenticity, not confidentiality.

What the signature proves

The third segment is what separates a JWT from an arbitrary base64 blob. For an HMAC token, the signature is computed as HMAC-SHA256(base64(header) + "." + base64(payload), secret). The server that issued the token holds the secret; when the token comes back on a later request, the server recomputes the HMAC over the first two segments and compares it to the signature presented. If a single bit of the payload changes — say someone edits their role from user to admin — the recomputed signature will not match and the token is rejected.

For RS256 and ES256 the same idea uses asymmetric cryptography: the identity provider signs with a private key and services verify with the corresponding public key, which can be published at a JWKS endpoint. This is how OAuth and OpenID Connect let dozens of services verify tokens minted by one identity provider without sharing secrets.

There is a famous pitfall here: the alg: none attack. If a verification library accepts a token whose header says "alg": "none" — meaning unsigned — an attacker can forge arbitrary claims. Always pin the expected algorithm in your verification code, and never accept tokens unsigned. When you test your own tokens locally, our JWT signature verifier shows you whether the HMAC matches your secret so you can be confident your signing code is correct.

Expiration, not-before, and the clock

Two claims do most of the security work in day-to-day operation. exp (expiration time) is a Unix timestamp after which the token must be rejected; short expirations — minutes to an hour for access tokens — limit the window in which a stolen token is useful. nbf (not before) works in the opposite direction: the token is invalid until that timestamp, which is handy for scheduled access or clock-skew-safe token rotation.

Because exp and nbf are compared against the verifying server’s clock, most libraries allow a small "leeway" of a few seconds to tolerate drift between machines. A token that decodes perfectly but is rejected with a 401 is very often simply expired, or was minted for a different environment whose clock differs. Decoding the token and reading the human-readable timestamps — rather than guessing — is the fastest way to settle those debugging sessions.

Where JWTs shine — and where they do not

JWTs are a great fit for **stateless authentication**: a service verifies the signature locally without a database lookup or a session store, which scales beautifully across many API instances. They are also the natural choice for **service-to-service tokens** and for federated identity with OpenID Connect, where one issuer is trusted by many applications.

They are the wrong tool when you need tokens to be instantly revocable. Because a valid signature is self-authenticating, a logged-out user’s access token remains valid until it expires unless you add a denylist — which reintroduces server-side state. They are also wrong for carrying sensitive data: remember, the payload is readable by anyone. Never put passwords, secrets or personal data in claims; if the payload must stay confidential, use an encrypted token (JWE) instead.

Finally, keep tokens short-lived and transport them over HTTPS only, preferably in the Authorization header rather than in cookies unless you explicitly need the browser to send them automatically — and if you do use cookies, set HttpOnly, Secure and SameSite appropriately.

A practical debugging workflow

When authentication breaks, work through the token in order: decode the header and payload to confirm the claims are what you expect; check exp and nbf against the current time; confirm iss and aud match what the verifying service expects; and only then verify the signature with the correct secret or public key. The free JWT Parser & Validator performs the first three steps automatically and supports HS256/HS384/HS512 signature verification locally, so you can debug without pasting production tokens into an unknown website.

Understanding JWTs removes most of the mystery from modern authentication: they are just signed, structured, time-limited claims. Treat the payload as public, protect the signing key, pin the algorithm, keep lifetimes short — and the format will serve you reliably.