What Is a JWT? Structure, Claims & Safe Validation

JWT in one minute

A JSON Web Token (JWT) is a compact way to carry a set of claims between systems. It is often used after a user signs in: an identity provider issues a token, and an API checks it on later requests. A JWT is a format, not a complete authentication system. Its safety depends on how it is created, signed, transported, and validated.

The three parts

A signed JWT commonly looks like header.payload.signature. The first two segments are Base64URL-encoded JSON. The header describes token metadata, such as a token type and signing algorithm. The payload contains claims: statements such as a subject (sub), issuer (iss), audience (aud), and expiration time (exp). The final segment is a cryptographic signature over the encoded header and payload.

Base64URL encoding makes the first two parts convenient to transport; it does not encrypt them. Anyone who receives a typical signed JWT can decode its header and payload. Do not put passwords, API keys, or other secrets in claims unless the token is separately encrypted using an appropriate standard.

Decode is not verify

Reading a token tells you what it claims to say. It does not show that the issuer signed it, that it has not expired, or that it was intended for your application. A malicious party can create a token with plausible-looking claims and an invalid signature.

On the server, use a maintained JWT library and an explicit verification policy. Validate the signature with a trusted key, restrict accepted algorithms, check the expected issuer and audience, and enforce expiration and any required application-specific claims. Do not choose a verification algorithm based only on an untrusted token header.

Common claims

• iss identifies the issuer; compare it to an expected trusted issuer.
• sub identifies the subject, usually a user or service.
• aud identifies intended recipients; reject tokens for a different API.
• exp is the expiry time, expressed as a NumericDate in seconds since the Unix epoch.
• nbf says the token should not be accepted before a specified time.
• iat records when the token was issued; it is not, by itself, an expiry check.

The exact claims and their meaning depend on the issuing system and your application. Treat unknown or optional fields according to documented policy rather than making assumptions.

Inspect a token carefully

For debugging, paste a test token into the JWT Decoder to inspect its header and claims locally. The decoder does not validate signatures or decide whether a service should accept the token. Never paste production credentials into a shared device, screenshot, ticket, or public log. If a token may have been exposed, revoke or rotate it using the issuer's supported process.

Use decoding to understand token structure. Use trusted server-side verification to make access-control decisions.