JWT Decoder — header, payload, signature

Paste any JSON Web Token and see its three parts decoded side-by-side. Standard claims like exp, iat and nbf are converted to readable dates and the expiry status is highlighted in real time.

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe representation of a set of claims to be transferred between two parties. It's three Base64URL-encoded parts separated by dots: a header (algorithm and token type), a payload (the claims as a JSON object) and a signature that proves the token wasn't tampered with.

JWTs power session management on most modern web stacks: an auth server signs them after login, the client sends them in the Authorization header on each request, and the API verifies the signature using a shared secret (HS256/HS384/HS512) or a public key (RS256, ES256, EdDSA). The payload itself is not encrypted — only signed — so anyone can read its claims by decoding the middle segment, exactly what this tool does.

How to use this tool

Paste a JWT in the input area, or click 'Load sample' to try with an example token.
The header, payload and signature are decoded into the three columns instantly. Standard time claims (exp, iat, nbf) are also shown as ISO 8601 dates next to their raw value.
If the payload contains an exp claim, the panel shows whether the token is still valid or already expired (red). The signature pane only shows the raw value — verifying it requires the secret or public key, which must stay on the server.

Frequently asked questions

Does this verify the JWT signature?

No — and intentionally so. Verifying a signature requires the secret (for HS*) or public key (for RS*/ES*/EdDSA), and exposing those in a browser tool would defeat the security model. This decoder shows the claims; verification belongs in your backend or your auth library.

Is the JWT sent to a server?

No. Decoding happens entirely in your browser using atob() and JSON.parse(). Your token never leaves your machine, so it's safe to inspect production tokens here.

What are the standard claims I should know?

The most common ones are: iss (issuer), sub (subject — usually the user ID), aud (audience), exp (expiration), nbf (not-before), iat (issued at) and jti (unique token ID). Any other field is application-specific.

What's the difference between JWT and JWS / JWE?

JWS (JSON Web Signature) is the format JWT uses by default — the payload is signed but readable. JWE (JSON Web Encryption) wraps the payload in a true encryption envelope so it can't be read without the key. 'JWT' colloquially almost always means JWS.

Why does my token's exp / iat look like a 10-digit number?

It's a Unix timestamp in seconds (RFC 7519 specifies seconds, not milliseconds). 10 digits is seconds, 13 digits would be milliseconds. This decoder converts whichever it sees into a readable ISO 8601 date so you can spot expiry at a glance.

Common use cases

Real situations where reading a JWT in your browser saves time.

Debug an authentication issue

A request is failing with 401 — paste the Authorization header value and check whether the token is expired, has the wrong audience, or simply lacks the scope your endpoint needs.

Audit issued claims

Your auth provider just rolled a new permission model — decode a fresh token to see which claims actually land in production tokens vs what the docs promise.

Inspect a third-party token

A vendor sent a webhook with a signed JWT proof — decode it to confirm the issuer, the subject and any custom claims before wiring up your handler.

Teach JWTs to a teammate

Hand over a sample token and let them see the three parts decode in real time — far more illuminating than a slide deck.

Tips and shortcuts

Habits that keep JWTs from biting you in production.

Never trust an unverified JWT

Decoding is not validation. Always verify the signature with the right key on the server before trusting any claim — even sub or exp.

Keep the payload small

JWTs go on every request. A 4 KB token kills mobile-network latency. Carry only the claims you actually use; fetch the rest server-side if needed.

Set a sensible exp

Hours, not weeks. Combine a short-lived access token with a longer-lived refresh token kept in an HTTP-only cookie. That gives you revocation without server-side session storage.

Don't put secrets in the payload

JWS payloads are signed but not encrypted. Anyone with the token can read the claims. If you need confidential data per user, use JWE or just keep the data server-side and reference it by an opaque ID.