JWT Demystified: From "What Is This Gibberish" to "Oh, That Makes Sense"

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.