Understanding JWTs: What's Inside a JSON Web Token

JSON Web Tokens (JWTs, often pronounced “jots”) are everywhere in modern authentication — they’re how a lot of APIs and single-sign-on systems prove who you are. They look like an intimidating blob of random characters, but the structure is simple once you see it. This guide breaks down what’s inside a JWT and, crucially, what it does and doesn’t protect.

The three parts

A JWT is three chunks separated by dots: header.payload.signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWRhIn0.SflKx...
└──── header ────┘ └──────── payload ────────┘ └ signature ┘

• Header — says what type of token it is and which algorithm signed it (e.g. HS256).
• Payload — the actual data (“claims”): who the user is, when the token expires, and any other info the app included.
• Signature — a cryptographic stamp that lets the server verify the token hasn’t been tampered with.

The header and payload are just Base64URL-encoded JSON — which means anyone can read them. Paste a token into the JWT Decoder to see the decoded header and payload instantly.

The most important point: a JWT is signed, not encrypted

This is the thing people get wrong. The payload is encoded, not encrypted — anyone who has the token can decode and read it. So never put secrets in a JWT payload: no passwords, no credit-card numbers, no private data you wouldn’t want the token-holder to see.

What the signature does guarantee is integrity: if anyone changes even one character of the payload, the signature no longer matches, and the server rejects the token. So a JWT can’t be forged or altered without the secret key — but it can absolutely be read.

Reading the standard claims

Payloads use short, standardized claim names. The ones you’ll see most:

• sub — the subject (usually the user ID).
• iat — “issued at,” a Unix timestamp of when the token was created.
• exp — “expires,” a Unix timestamp after which the token is invalid.
• iss / aud — who issued the token and who it’s intended for.

A good decoder translates iat and exp into readable dates so you can see at a glance whether a token is still valid — handy when an API keeps returning “unauthorized” and you suspect the token has expired.

A safety note about decoding tokens

Decoding only reads the token; it doesn’t verify the signature (that needs the secret key and should happen on the server). Because a live token is effectively a temporary password, be careful where you paste production tokens. Toolify’s decoder runs entirely in your browser and never transmits the token — but as a habit, avoid pasting real credentials into any online tool, and decode expired or test tokens when you can.