What is a JWT? A 5-minute developer guide

JSON Web Tokens explained without jargon — what they are, what they're not, how to decode one, and when to use them.

If you've worked with any modern web auth system in the last decade, you've probably seen a long string starting with eyJhbGc… and been told it's a JWT. Here's what it actually is, what it isn't, and when you should care.

What a JWT is

A JSON Web Token is a compact, URL-safe way of passing a small amount of information between two systems, signed so the recipient can verify the data hasn't been tampered with.

It's made of three pieces, joined by dots:

<header>.<payload>.<signature>

Each piece is JSON, encoded as Base64URL. Decode them and you get readable data.

What's in each part

Header — declares the signing algorithm (typically HS256 or RS256) and that this is a JWT.
Payload — the actual data. Standard fields (called “claims”) include sub (subject / user id), exp (expiry, as a Unix timestamp), iat (issued at), and any custom fields the app adds.
Signature — a hash of the header + payload, signed with a secret only the issuing server knows. This is what prevents tampering.

What a JWT is NOT

Two common misunderstandings:

A JWT is not encrypted. The header and payload are encoded, not encrypted. Anyone with the token can decode and read the contents. Don't put secrets in the payload — only put things the user is allowed to know (their own user ID, role, etc.).
A JWT is not magic. The signature only proves the token was issued by someone with the secret. It doesn't prove the token is still valid — you still need to check exp and any custom rules on the server.

When JWTs are the right choice

Stateless API auth. The server can verify the token's signature and trust the claims without looking up anything in a database.
Single sign-on (SSO). One service signs a token, another service verifies it using the public key.
Short-lived access tokens paired with longer refresh tokens (the pattern Uvelia uses for auth).

When JWTs are the wrong choice

Long-lived sessions. Once issued, a JWT can't be revoked until it expires. For sessions that can last weeks, opaque tokens checked against a server-side store are safer.
Containing more than ~1 KB of data. JWTs go in every request — large tokens slow everything down.
When you don't need them. If everything runs on one server, regular session cookies are simpler.

How to decode a JWT

Any JWT can be split on the dots and Base64URL-decoded to read its contents. To do this in your browser without copy-pasting the token into a random online tool, use Uvelia's JWT Decoder — it processes everything locally so the token never leaves your device. It also detects expired tokens and shows you iat / exp claims as readable ISO dates.

The single most important security tip

Always verify the signature server-side before trusting any claim in the payload. Decoding a JWT is trivial — and attackers can forge a payload claiming whatever they want. Only the signature check (using the secret you've never published) separates a real token from a forged one.

Decoding without verifying is fine for debugging (which is what Uvelia's decoder does — it never claims to verify). It is never fine on a server processing a request.