JWT Decoder

Open up a token's header and payload — without sending it anywhere.

Your data is processed entirely in your browser and is never uploaded.

Tool workspace

INPUT TOKEN
Token: Empty0 chars

Decode

Decoded, not verified.We have no key — this token's signature is not checked here. Never treat a decoded payload as trustworthy.
Local sandbox active
DECODED
Output: Empty0 chars
HOW IT WORKS

Decode a JWT in three steps

Paste the token

A full header.payload.signature string — a leading "Bearer " is stripped for you.

Decode

Header and payload are base64url-decoded and pretty-printed, right on your machine.

Read the claims

exp / iat / nbf become human dates with an expired / valid-so-far indicator.

Docs · JWT

What decoding is (and what it is not)

A JWT is three base64url segments joined by dots: a header, a payload, and a signature. The first two are encoded, not encrypted — anyone holding the token can decode and read them, which is exactly what this tool does, entirely in your browser. The signature is what a verifier checks against a key; this page has no key, so it decodes and stops, and says so loudly. Reading the payload tells you what the token claims; it never tells you whether those claims are true.

Things to know

Decoded ≠ verified

Anyone can base64-encode a payload that says admin: true. Only the holder of the signing key can produce a signature that verifies. This tool shows you the claims; it cannot and does not vouch for them.

exp / iat / nbf are time facts

Numeric date claims are rendered as human dates with an expired / valid-so-far indicator. That's a statement about the clock, not about authenticity — an expired token can still be a genuine one, and a valid-looking one can still be forged.

Wrong number of segments

A JWS (the common JWT) has exactly three dot-separated parts. Load this and the decoder tells you the count it found.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0
alg: none

A token declaring alg none with an empty signature is unsigned — anyone could have made it. The decoder flags this loudly; servers that accept such tokens are vulnerable.

Try these

The classic sample
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The canonical example token — HS256, with an iat claim to interpret.

pair this withDecode raw Base64 → Base64 Encode / Decode·Format the payload → JSON Formatter·Validate the payload → JSON Validator

FAQ

Frequently asked questions

Does this verify my token's signature?

No — and it can't. Verification needs the signing key (a secret or a public key), which only the issuer holds. This tool decodes the visible parts and tells you plainly that the signature was not checked. Anyone who warns you otherwise is guessing.

Is my token uploaded anywhere?

No. Decoding is base64url + JSON.parse, done entirely in your browser. Tokens are credentials — pasting one into a site that uploads it is how they get stolen. This one has no network path for it to travel.

What does "expired" mean here?

It's a time fact, not a signature fact. If the exp claim is in the past, the token is expired by its own terms — but that says nothing about whether it was ever legitimately signed.

What about alg: "none"?

A token with alg: "none" and no signature is unsigned — anyone could have created it. The decoder calls this out loudly. Servers that accept such tokens have a serious vulnerability.