What Is a JWT, and What's Inside One?

A JSON Web Token is the little string that keeps you logged in and that APIs pass around to prove who is calling. Here is what its three parts actually contain, why anyone can read them, and what the signature on the end really proves.

Where you meet JWTs

If you have signed into a modern web app, you have almost certainly carried a JWT around without noticing. They show up in a few common places:

• Login sessions. After you sign in, a service often hands your browser a token instead of keeping a session record on the server. Your browser sends it back with each request, and the server reads it to know who you are.
• API authentication. When one program calls another's API, it commonly attaches a JWT in an Authorization: Bearer header to prove it is allowed to make the call.
• OAuth and OpenID Connect. When you "Sign in with Google" or a similar provider, the ID token you receive is typically a JWT describing who you are and which app the token was issued for.

The format itself is defined in RFC 7519, which standardizes what a JSON Web Token looks like and what its fields mean.

Three parts, separated by dots

A JWT is one long string with two dots in it, splitting it into three sections: header.payload.signature. Each section is Base64URL-encoded, which is a URL-safe variant of Base64 that swaps a couple of characters so the token can travel safely inside links and headers. Decoding a section just reverses that encoding; it does not require any password.

The header

The first part is a small JSON object describing the token itself. It usually names the token type (JWT) and the algorithm used to sign it, in a field called alg (for example HS256 or RS256). The signing-and-encoding structure that wraps the payload is specified separately, in the JSON Web Signature standard, RFC 7515.

The payload

The second part is another JSON object, this time holding the "claims": the actual statements the token is making, such as who the user is and when the token stops being valid. This is the interesting part for most people, and it is covered in detail below.

The signature

The third part is not readable JSON. It is a cryptographic value computed over the header and payload, and it is what lets a server check that nobody changed those first two parts after the token was issued.

The payload is readable, not secret

This is the point people most often get wrong, so it is worth stating plainly. The header and payload are encoded, not encrypted. Base64URL is reversible by anyone, with no key required. That means anyone who gets hold of a JWT can decode it and read every claim inside, including in their browser's developer tools or with a decoder like this page.

The practical rule that follows: never put anything sensitive in a JWT payload. No passwords, no API keys, no card numbers, no private personal details you would not want a third party to see. Treat the payload as if it were printed on the outside of an envelope. The signature seals the envelope so it cannot be altered without detection, but it does nothing to hide what is written on it.

If a token genuinely needs its contents hidden rather than just protected from tampering, there is a separate encrypted format (JSON Web Encryption) for that. A plain signed JWT, the kind you see most often, is not it.

The common claims, in plain terms

RFC 7519 reserves a handful of short claim names so different systems agree on what they mean. You will see most of these in a typical token:

• iss (issuer): who created and signed the token, usually an identity provider or your own auth server.
• sub (subject): who or what the token is about, most often a stable user ID.
• aud (audience): who the token is intended for. A service is supposed to reject a token whose audience is not itself, so a token minted for one app should not be accepted by another.
• exp (expiration time): the moment the token stops being valid, given as a Unix timestamp. A well-behaved server refuses an expired token.
• iat (issued at): when the token was created, also a Unix timestamp. Handy for judging how old a token is.
• nbf (not before): the earliest time the token should be accepted, useful for tokens meant to activate later.

Beyond these, issuers add their own custom claims for things like roles, email, or scopes. Those are application-specific and not part of the standard set, so their meaning depends on whoever issued the token.

What the signature does (and does not) prove

The signature is what turns a readable blob into something a server can trust. At a high level there are two common approaches:

• A shared secret (HMAC). With algorithms like HS256, the issuer and the verifier both hold the same secret key. The issuer mixes that secret with the header and payload to produce the signature, and anyone who knows the secret can recompute it to check the token. This is simple but means every party that verifies tokens also holds the signing key.
• A public/private key pair. With algorithms like RS256, the issuer signs with a private key it keeps to itself, and anyone can verify using the matching public key. Verifiers never need the private key, which is why this suits OAuth and OpenID Connect, where many services check tokens from one central issuer.

In both cases the signature proves two useful things: the header and payload have not been changed since they were signed, and the token was issued by someone holding the key. What it does not prove is that the contents are private. As covered above, the payload is still plainly readable. Tamper-evident is not the same as confidential.

An honest caveat about decoding

A decoder, including the one linked below, splits a token apart and shows you the header and payload in readable JSON. That is genuinely useful for debugging, for understanding what a token is asserting, and for spotting an obviously wrong audience or an expiry that has already passed.

But decoding is not verifying. A decoder shows the claimed contents without checking the signature against any key, so it cannot tell you whether the token is authentic, untampered, or issued by who it says. A decoded token is not a validated one. Only a server that holds the correct secret or public key, and that checks the signature along with exp, aud, and the other claims, can decide whether a token should actually be trusted. Use a decoder to read and learn, and leave the trust decision to the system that holds the key.

This guide is educational and reflects publicly available information about JSON Web Tokens and the published standards that define them. It is not legal advice or a security audit, and it is not a recommendation about any specific token, system, or decision. How you issue, store, and validate tokens should follow your organization's policies, your framework's guidance, and applicable law.