JWT Is Just Base64 in a Trench Coat — Decode It Online in Seconds

You’re staring at a network tab. There’s a request header that says Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c and your first reaction is: “What even is this?”

Good news: most of that string is just Base64. The scary-looking blob is wearing a trench coat, pretending to be more mysterious than it is. Let’s strip it off.

What a JWT Actually Is

A JSON Web Token is three Base64url-encoded chunks glued together with dots:

• Kopfbereich – algorithm and token type (e.g. {"alg":"HS256","typ":"JWT"})
• Nutzlast – the claims: user ID, roles, expiry, whatever the server decided to pack in
• Unterschrift – the part that actually enforces security

The header and payload are not encrypted. They are Base64url-encoded, which means anyone with the token can read them — no key required. The signature is the only thing that prevents tampering: changing a single character in the payload invalidates it.

To decode the payload right now: grab the second chunk (between the two dots), throw it into a Base64 decoder, and you’ll see plain JSON. That’s it. That’s the magic trick.

How to Decode a JWT in Seconds

The fastest way: paste your token into the JWT decoder at IOTools. It splits the three parts, decodes each one, and displays the header and payload as formatted JSON — no account, no setup, no “sign in to unlock the decoder.”

What you’ll immediately see in a typical payload:

• sub – subject (usually user ID)
• iat – issued-at timestamp (Unix epoch)
• exp – expiry timestamp
• iss – issuer
• Any custom claims your API shoves in: roles, permissions, plan tier, etc.

If you just need to know whether a token is expired without wiring up a full decoder, the JWT expiry checker reads the exp claim and tells you exactly how much life is left — or when it died.

The Three Gotchas That Burn Developers

1. The Expiry You Forgot to Check

Der exp field is just a number in the payload — the server is supposed to validate it, but plenty of older codebases don’t, or have a bug in timezone handling. If users are mysteriously getting logged out (or mysteriously staying logged in forever), decode the token and look at exp vs the current Unix timestamp. The expiry checker does this in one click.

2. Algorithm Confusion

The header’s alg field tells the verifier which algorithm to use. Some older JWT libraries would accept {"alg":"none"} and skip verification entirely — stripping the signature and treating any payload as valid. This is a known attack. Always verify your library enforces a specific algorithm allowlist and rejects none.

Another variant: RS256 (asymmetric) vs HS256 (symmetric). An attacker who knows your public key can forge a token by switching the header to HS256 and signing with the public key as the secret — if the library naively trusts the header’s alg claim. The fix: configure your library with an explicit algorithm, not “whatever the token says.”

3. Secrets in the Payload

Because the payload is Base64-encoded and not encrypted, anything you put in there is readable by the client (and anyone who intercepts the token over plain HTTP, though you’re using HTTPS everywhere, right?). Don’t put passwords, PII, or internal system details in JWT claims. The payload is for authorization metadata — not a place to store sensitive data.

Decode a token from your own app and see what’s in there. You might be surprised what a previous developer stuffed in years ago.

JWT vs Session Tokens: What’s Actually Different

The perennial debate. Here’s a direct comparison:

	JWT	Session Token
Where state lives	Inside the token (stateless)	Server-side (database or memory)
Revocation	Hard — token is valid until exp unless you maintain a blocklist	Easy — delete the session record
Skalierbarkeit	Good for distributed systems; no shared session store needed	Requires sticky sessions or shared store (Redis, etc.)
Payload visibility	Client can read claims (not encrypted)	Opaque to client
Storage risk	localStorage is XSS-vulnerable; httpOnly cookie is safer	httpOnly cookie (standard approach)
Token size	Larger — carries all claims inline	Small — just an ID
Best for	APIs, microservices, cross-domain auth	Traditional server-rendered web apps

Neither is universally better. JWTs shine when you need stateless auth across multiple services. Session tokens are simpler when you control the full stack and need instant revocation (e.g., “log out everywhere” for a security incident).

Debugging JWTs in Real Workflows

Here’s the typical sequence when something’s broken in an API that uses JWTs:

1. Copy the token from the failing request (Authorization header, query param, or cookie — wherever your API puts it)
2. Paste into the JWT decoder to see the raw claims
3. Prüfen exp — is the token expired? Use the expiry checker if you don’t want to do Unix timestamp math in your head
4. Prüfen iss und aud — does the issuer and audience match what your service expects?
5. Check the algorithm in the header — does it match your server config?
6. Check the signature format — three parts? Two? A tampered token sometimes shows up as two parts with no signature

Most JWT debugging dead-ends at step 3. The token was issued with a short TTL, cached somewhere, and arrived expired. This is boring and common.

The Signature: The One Part That Matters

The signature is computed as: HMACSHA256(base64url(header) + "." + base64url(payload), secret). The server generates it when issuing the token. When validating, it recomputes the same hash and compares. If the payload has been modified at all — even one character — the hash won’t match and the token is rejected.

This is why decoding a JWT to read the claims is safe and trivial, but forging one without the secret is not. The Base64 is the costume; the signature is the lock on the door.

For asymmetric algorithms (RS256, ES256), the signing key is a private key that never leaves the auth server. The verification key is a public key that any service can use — no shared secret required. This is the right architecture for microservices where multiple services need to verify tokens but only one should issue them.

Das könnte Ihnen auch gefallen