What Is a JWT Token? Structure and How It Works

A JWT token (JSON Web Token) is a compact, self-contained way to securely carry information between two parties — most often to prove that a user is logged in. If you build or use modern web apps and APIs, you meet JWTs constantly, so it helps to know exactly what they contain.

What a JWT is for

When you sign in to a site, the server can hand your browser a signed token instead of storing your session on its own database. On each later request your app sends the token back, and the server trusts it because the signature proves it has not been tampered with. This makes JWTs popular for stateless authentication across APIs and microservices.

The three parts of a JWT

A JWT is three Base64 sections joined by dots: header.payload.signature.

Part	What it contains
Header	The token type and signing algorithm.
Payload	The claims — user id, expiry, roles.
Signature	A cryptographic seal that verifies the token.

What lives in the payload

• sub — the subject, usually the user's id.
• exp — the expiry time, after which the token is invalid.
• iat — when the token was issued.
• Custom claims such as roles or permissions.

A key safety point

The header and payload are only Base64-encoded, not encrypted — anyone can read them. Never put passwords or secrets inside a JWT payload.

How to inspect a token

Because the readable parts are just Base64, you can decode any token to see its contents. Our JWT decoder splits a token and shows the header and payload as clean JSON, entirely in your browser, and if you want to understand the underlying encoding first, the Base64 tool shows how each part is built. The formal specification is RFC 7519. Decode a real token once and the structure will click immediately.

Decoding is not verification

A JWT decoder can display the header and payload because those segments are Base64url-encoded, not encrypted. That is useful for debugging expiry times, audiences and issuer names, but it proves nothing about authenticity. A server must verify the signature with an allowed algorithm and the correct secret or public key before trusting any claim.

Never grant access because a payload says role: admin. Trust claims only after signature, issuer, audience and time checks succeed.

Claims that deserve explicit validation

Claim	Meaning	Check
iss	Issuer	Must equal an issuer configured by the application
aud	Audience	Must include the service receiving the token
exp	Expiry	Reject after this Unix timestamp, with only limited clock tolerance
nbf	Not before	Reject before this time
sub	Subject	Interpret only within the verified issuer's namespace

Common implementation failures

• Accepting the algorithm named by an untrusted header without an allowlist.
• Skipping audience or issuer checks because the signature is valid.
• Putting passwords, payment details or private personal data in the readable payload.
• Giving long-lived access tokens no revocation or rotation strategy.
• Logging complete tokens where support staff, analytics systems or error trackers can read them.

Storage and transport choices

Send tokens only over HTTPS. Browser storage involves trade-offs: JavaScript-readable storage increases exposure to cross-site scripting, while cookies require secure attributes and CSRF-aware design. There is no universal storage rule; the architecture, threat model and framework protections matter. Keep access tokens short-lived and use a deliberate refresh process where needed.

Safe inspection workflow

1. Use a fabricated or already-revoked token for debugging whenever possible.
2. Decode locally and inspect only the fields needed for the problem.
3. Check numeric dates as Unix seconds, not milliseconds.
4. Verify the same token in the application using its trusted key configuration.
5. Remove tokens from logs, tickets and screenshots after diagnosis.

JWT is a compact message format, not a complete authentication system. Session management, key rotation, logout behavior, account recovery, authorization and monitoring still need separate design and testing.