JWT Decoder & Debugger

How to use this JWT decoder

Paste your token into the box above and the decoder does the rest — it works live as you type, so there's nothing else to press unless you want to. The header and payload appear as formatted JSON in the two panels, and anything time-sensitive gets flagged automatically: an expired exp claim raises a warning, a nbf (not-before) claim sitting in the future gets called out, and a malformed token produces a plain-English error instead of a blank stare.

Use the copy buttons to grab the raw JSON, or hit Load sample token to watch a clean decode before pasting your own. If your token is signed with HS256 and you hold the secret, drop it into the verification field to confirm the signature is intact. Everything runs locally — open your network tab and you'll see exactly zero requests leave the page.

What is a JWT, actually?

JWT stands for JSON Web Token — a compact, self-contained way to pass signed claims between two parties, standardized in RFC 7519. "Self-contained" is the part that matters: unlike a session ID, which means nothing until a server looks it up in a database, a JWT carries its own data. The server signs it, hands it to the client, and from then on can trust the contents simply by checking the signature — no database round-trip on every request.

That's why JWTs are everywhere in modern authentication. You log in, the API returns a token, and your client sends it back in the Authorization: Bearer <token> header on every subsequent request. The payload typically holds your user ID (sub), maybe a role or scopes, and an expiry time (exp).

One thing trips people up constantly: a JWT is signed, not encrypted. Anyone can decode the payload — which is precisely what this tool does. The signature only proves the token wasn't modified in transit; it hides nothing. So never put passwords, API keys, or personal data in claims.

Anatomy of a JWT

Every JWT is three base64url-encoded strings joined by dots: header.payload.signature. Here's a real (demo) token pulled apart:

# 1 · header — algorithm & token type
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

# 2 · payload — the claims (the actual data)
eyJzdWIiOiJ1c3JfOGYyazEiLCJuYW1lIjoiRGVtbyBVc2VyIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzUxMzI4MDAwLCJleHAiOjIwMDAwMDAwMDB9

# 3 · signature — proves parts 1 & 2 weren't tampered with
oXT5B2zaZUbxFrrqOs8iM5yTkROnpftWCffbqzRMZGI

The header

Metadata about the token. Almost always two fields: alg (the signing algorithm, e.g. HS256 or RS256) and typ (simply JWT). Decoded, the header above reads {"alg":"HS256","typ":"JWT"}.

The payload

The claims — the actual information. Registered claims have standard names: sub (subject), iat (issued at), exp (expiry), nbf (not before), iss (issuer), aud (audience). On top of those, you can add anything custom, like "role": "admin" above. Timestamps are Unix epoch seconds, which is why this tool converts them to readable dates for you.

The signature

For HS256, it's HMACSHA256( base64url(header) + "." + base64url(payload), secret ). Change a single character in the header or payload and the signature stops matching — which is how the server detects tampering. Without the secret, you can read a token but you can't forge a valid one.

When developers actually reach for this

• Debugging a rejected request. "Why is the API returning 401?" is often an expired token — decode it and the exp claim tells you instantly.
• Inspecting what the server actually said. Check which roles, scopes, or permissions the auth server put in your token without writing a single line of code.
• Catching clock-skew bugs. An iat in the future or an exp that's seconds off points straight at a server timezone problem.
• Verifying transport integrity. Confirm a token survived a copy-paste through Slack, a log file, or a proxy without losing a character.
• Learning and teaching. Seeing the three parts decoded side by side is the fastest way to understand how token auth actually works.

Security notes worth knowing

A decoder is a reading tool, not a trust tool. A few things bite people often enough to spell out:

• Decoded ≠ verified. Anyone can produce a token that decodes to "role":"admin". Never make authorization decisions client-side from decoded claims — only a server holding the secret or public key can confirm they're genuine.
• The alg:none attack. Historically, some libraries accepted tokens with no signature at all if the header said "alg":"none". Always enforce the expected algorithm server-side; never let the token choose it for you.
• exp is a courtesy unless enforced. The claim only means something if the server actually checks it. This tool flags expiry for your convenience; the real gatekeeper is the API.
• Think about where you store tokens. localStorage is readable by any JavaScript on the page (an XSS risk); httpOnly cookies aren't. Neither is universally "correct" — but knowing the trade-off is the whole game.
• Claims are public. Signed, not encrypted. If you wouldn't print it on a sticker, don't put it in a JWT.

Frequently asked questions

Related guides