JWT Explained: Header, Payload, Signature, and Common Pitfalls

It was 3 PM on a Tuesday. I had been staring at a Postman response for five minutes—a long string starting with eyJhbGciOiJIUzI1....

The backend developer said: "The token is expired. Just log in again."

I asked: "How do you know it's expired?"

He looked at me like I had asked why water is wet: "Just decode it and look."

That was the first time I realized that gibberish-looking string could actually be "decoded and looked at."

What Is That String Anyway

JWT, which stands for JSON Web Token, is a compact token format defined by an open standard (RFC 7519). The name comes from the fact that its core content is JSON data, encoded in a way that makes it URL-safe.

A JWT has three parts, separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0NX0.xxxxx

They are:

• Header: Describes what algorithm was used to sign the token
• Payload: The actual data (like user ID, expiration time)
• Signature: Used to verify the first two parts haven't been tampered with

Here's the interesting part: the first two sections are just Base64-encoded, not encrypted. Anyone who gets this token can decode and read the contents. This isn't a design flaw—it's intentional.

Why No Encryption

Many people's first reaction is: "Isn't that insecure?"

It depends on what you mean by security. JWT isn't designed for secrecy; it's designed for integrity. The payload is public, but you can't modify it—because the signature was generated using a secret key that only the server knows.

Think of it like a sealed letter with an official stamp. Anyone can read the letter, but nobody can forge the stamp.

If you do need encrypted payloads, there's JWE (JSON Web Encryption) for that. Different standard, different use case.

Lessons Learned the Hard Way

Mistake 1: Putting sensitive data in the payload

I've seen people store passwords, credit card numbers, and API keys in JWT payloads. Please don't. It's just Base64—any online tool can decode it. Only put information that needs to be verified, not hidden.

Mistake 2: No expiration time

JWTs are stateless by design. If you don't set an exp claim, the token is valid forever. Someone leaks your token? They can impersonate you indefinitely.

Mistake 3: Expiration too long

The other extreme: 30-day expiration. That means after a user changes their password, old tokens still work for a month. The solution is refresh tokens—short-lived access tokens (15 minutes) paired with longer-lived refresh tokens.

Mistake 4: Storing in localStorage

XSS attacks can steal your token in seconds. HttpOnly cookies are safer—JavaScript can't access them at all.

The Developer's Daily JWT Routine

During development, the most common need is simply "what's inside this token?"

You want to check:

• Is the user ID correct?
• When does it expire?
• Is the issuer what you expect?

Going to random online tools every time? Annoying. Using base64 -d in the terminal? The output is a mess.

That's why we built this JWT decoder. Paste your token, see the formatted Header and Payload, get the expiration time in human-readable format, and know immediately whether the token is valid, expiring soon, or already expired.

Nothing fancy. Just making a common task less painful.

What to Double-Check

Check	Why it matters
Input shape	Small examples can hide optional fields, nulls, escaping, or platform differences.
Runtime behavior	Browsers, Node.js, Python, Java, AWS, and Quartz may parse similar syntax differently.
Copy safety	Remove tokens, passwords, customer data, and private IDs before using online tools.
Regression test	Save one example that failed so the same bug does not return later.

FAQ

Is an online tool enough for production code?

It is enough for inspection, formatting, and first-pass generation. Production code should still be validated with tests, schema checks, or the runtime that will actually execute it. In practice, pair this step with the output from Decode Your JWT.

Security checks that matter

Learn what a JWT contains, how header, payload, and signature work, and which security mistakes to avoid when debugging authentication tokens. Security-related tools are useful for inspection, but the enforcing system still decides whether something is valid. A decoded token, generated password, or matching checksum should be checked against the backend, password manager, release page, or account policy that actually matters.

Use Decode Your JWT with non-sensitive inputs when possible. If you need to inspect a real value, avoid pasting secrets into untrusted places, record the source of the expected result, and keep the final verification tied to the official system.