JWT Decoder

Decode a JSON Web Token and read its header and payload claims as formatted JSON. Decoding only — the signature is not verified.

Your token is decoded entirely in your browser. It is never sent anywhere.

Decoding is for inspection only. The signature is not verified here.

What's Inside a JWT?

A JSON Web Token (JWT) is a compact, self-contained way to pass claims between parties. It packs a header, a payload and a signature into three dot-separated base64url strings, and — because every piece is plain-encoded — you can open it up and read what is inside without any key. This tool does exactly that: it splits your token and pretty-prints the two halves.

Header, payload, signature
The first segment (header) declares the token type ("JWT") and the signing algorithm (HS256, RS256, ES256…). The second segment (payload) holds the claims: standard ones like sub (subject), iss (issuer), exp (expiration), iat (issued at), plus custom claims like user ids and roles. The third segment (signature) is the HMAC or asymmetric signature over the first two, which is what actually protects the token.
Why decoding needs no key
Base64url is an encoding, not encryption — it obfuscates nothing. The cryptographic protection is the signature alone, and verifying it requires the issuer's secret (HMAC) or public key (RSA/EC). So reading a token is free for anyone, but forging or tampering with one is not: any change to the header or payload invalidates the signature.
When verification matters
Whenever code makes decisions based on a token — authenticating a user, granting access, trusting an exp — it must verify the signature with the issuer's key, check the algorithm against an allowlist, and validate exp, nbf, iss and aud. Decoding, like this tool does, is only ever a debugging aid.

Frequently Asked Questions

What are the three parts of a JWT?

A JWT is three base64url-encoded segments joined by dots: header, payload and signature. The header says how the token was signed (algorithm like HS256 or RS256, plus the type). The payload carries the claims — user id, roles, expiry (exp), issuer (iss) and so on. The signature is the cryptographic proof that the other two parts were not tampered with.

Why can I decode a JWT without the secret key?

Decoding and verification are different operations. The header and payload are plain base64url — no cryptography is applied to them, only to the signature. Anyone can decode a JWT to read its contents; only someone holding the signing key (or the public key, for asymmetric algorithms) can verify that it is genuine and untampered.

When do I actually need to verify a JWT?

Every time a system acts on a token: an API checking an auth token, a server validating a session, or code trusting an exp claim. Verification checks the signature against the issuer's key, confirms the algorithm matches what you expect, and validates expiry, issuer and audience. Never trust a JWT's contents until its signature has been verified by the party that issued it.

What is the difference between a JWT and a session cookie?

A session cookie is an opaque handle: the server keeps the actual session data and the cookie just references it. A JWT is self-contained: all the claims travel with the token, so a stateless service can check it without a database lookup. The tradeoff is that a JWT cannot be revoked before it expires — you have to wait it out or add a blocklist.

Is my token sent anywhere when I use this tool?

No. The token is decoded entirely in your browser tab with JavaScript's built-in base64 functions. It never leaves your device, is not logged and is not stored anywhere. Treat any page that asks for a token and sends it to a server with the suspicion it deserves.