What Is a JWT and How Do You Decode One?

If you've worked with any modern web API, you've almost certainly encountered a JWT. They appear in Authorization headers, cookies, local storage — and they look like a long, incomprehensible blob of characters. But they're actually quite simple once you understand the structure.

This guide explains what JWTs are, what's inside them, how to safely decode one, and when you should (and shouldn't) trust them.

What Is a JWT?

JWT stands for JSON Web Token. It's a compact, URL-safe token format used to transmit information between parties — most commonly to verify that a user is authenticated. The JWT specification is defined in RFC 7519.

A JWT looks like this:

It has three parts separated by dots: a Header, a Payload, and a Signature. Each part is Base64URL-encoded.

The Three Parts of a JWT

1. Header

The header declares the token type and the signing algorithm used:

2. Payload (Claims)

The payload contains the actual data — called claims. These are statements about the user or the token itself:

3. Signature

The signature is created by signing the header + payload with a secret key. It's what allows the server to verify that the token hasn't been tampered with. Without the secret key, you can read the payload but you cannot produce a valid signature.

How to Decode a JWT

Decoding a JWT means reading the header and payload. This doesn't require the secret key — it's just Base64URL decoding. Here's how to do it instantly:

1. Copy your JWT token
2. Open EazyStudio's JWT Decoder
3. Paste the token — the header, payload, and expiry are shown immediately
4. Check the exp claim to see if the token has expired

Verifying a JWT (vs. Just Decoding)

There's an important distinction between decoding and verifying a JWT:

• Decoding — reading the payload. Anyone can do this. No secret needed.
• Verifying — checking the signature to confirm the token is authentic and unmodified. Requires the secret key (or public key for RS256).

When debugging, you just want to decode — to see what's in the token. When your server processes a user request, it must verify — to confirm the token is trustworthy. Never skip verification on the server side.

Common JWT Claims Explained

Claim	Meaning
sub	Subject — usually the user ID
iss	Issuer — who created the token
aud	Audience — who the token is intended for
exp	Expiration time (Unix timestamp)
iat	Issued at (Unix timestamp)
jti	JWT ID — unique identifier for the token

When Should You Use JWTs?

JWTs are great for:

• Stateless authentication — the server doesn't need to store session data; all info is in the token
• Microservices — services can verify tokens independently without a central session store
• Single-page apps (SPAs) — tokens stored in memory or cookies, sent with each API request

JWTs are not ideal for:

• Scenarios where you need to invalidate tokens before expiry (e.g., "log out everywhere") — unless you maintain a token blocklist
• Storing large amounts of data — tokens get large and are sent with every request