What Is a JWT Token and How to Decode It Safely

JWT (JSON Web Token) shows up constantly in modern authentication — in Authorization headers, cookies, and API responses — but it's easy to use one for months without knowing exactly what's inside it.

What a JWT actually is

A JWT is a compact, URL-safe string used to represent claims between two parties, most commonly to prove a user is authenticated after logging in. It isn't encrypted by default — it's encoded and signed, which means anyone holding the token can read its contents, but can't alter them without invalidating the signature.

The three parts of a JWT

A JWT is always three Base64URL-encoded segments separated by periods: header.payload.signature.

Header

The header identifies the signing algorithm (commonly HS256 or RS256) and the token type. It's small and rarely interesting on its own.

Payload

The payload holds the actual claims — data like a user ID, an expiration timestamp (exp), an issued-at timestamp (iat), and any custom fields the issuing server chose to include. This is the part developers usually care about when debugging an auth issue.

Signature

The signature is generated by combining the encoded header and payload with a secret (or private key) and running them through the algorithm named in the header. It's what lets a server confirm the token hasn't been tampered with — without the correct secret, changing even one character of the payload invalidates the signature.

Decoding vs verifying — an important distinction

Decoding a JWT just means Base64URL-decoding the header and payload to read them as plain JSON — no secret required, since that part isn't encrypted. Verifying a JWT means checking the signature against the secret or public key to confirm it's authentic and hasn't been altered. A tool that only decodes a token is showing you its contents, not proving they're trustworthy — never treat a decoded payload as verified unless the signature has actually been checked server-side.

Where you'll run into JWTs

JWTs show up in a handful of common patterns:

• Single sign-on (SSO) — an identity provider issues a JWT after a successful login, and other services trust the signature instead of re-checking a password themselves.
• Stateless API authentication — instead of looking up a session ID in a database on every request, a server can verify a JWT's signature and read the user ID straight from the payload, which scales more easily across multiple servers.
• OAuth 2.0 access tokens — many OAuth providers issue JWTs as access tokens, encoding scopes and an expiration directly in the token instead of requiring a separate lookup for every request.

A decoded payload for a typical session token might contain fields like these:

1. sub — the subject, usually a user ID.
2. name or role — custom claims the issuing server chose to include, such as a display name or permission level.
3. iat — issued-at time, in Unix time (seconds since January 1, 1970).
4. exp — expiration time, in the same Unix time format, after which the token should be rejected.

Common mistakes when working with JWTs

1. Treating an unverified token as trusted — always verify the signature server-side before acting on any claim inside it.
2. Storing sensitive data in the payload — since the payload is readable by anyone holding the token, avoid putting passwords, secrets, or personal data inside it.
3. Ignoring the exp claim — a token that's never checked for expiration can be replayed indefinitely if it leaks.
4. Assuming a longer token is more secure — length just reflects how many claims it carries, not how well it's protected.

Decoding safely

Because a JWT's payload is plain, readable JSON once decoded, pasting one into an online tool can expose whatever claims it contains — user IDs, emails, roles, sometimes more than developers expect. Use a decoder that runs entirely in your browser and never transmits the token anywhere, especially with tokens pulled from a production environment.

Try it

The JWT Decoder on this site decodes the header and payload entirely client-side — nothing you paste is ever sent to a server, which makes it safe to inspect real tokens while debugging.