JWT Decoder & Inspector
Paste a JSON Web Token to decode its header and payload, inspect claims, and check expiry. The signature is not verified — that requires the secret key. Everything runs in your browser.
About this tool
Decodes the two Base64URL-encoded parts of a JWT — the header and the payload — and pretty-prints them with syntax highlighting. Registered time claims (exp, iat, nbf) are converted to human-readable dates, and the token is flagged as expired or still valid. The signature is displayed but not verified, since verification requires the key.
Your token never leaves the page — decoding happens entirely in your browser with no server, no upload, and no logging of tool inputs.
Frequently asked questions
Is it safe to paste a JWT into an online decoder?
This decoder runs entirely in your browser — the token is never transmitted, logged, or stored anywhere. That said, a live JWT is a bearer credential: anyone who has it can use it until it expires. As a habit, only paste production tokens into tools you trust, prefer expired or test tokens when debugging, and never paste the signing secret itself into any website.
Why doesn't this tool verify the signature?
Verifying a signature requires the signing key — the shared secret for HMAC algorithms like HS256, or the public key for RSA/ECDSA algorithms like RS256 and ES256. A decoder without the key can only read the token, not vouch for it. Decoding is not validation: your server must always verify the signature and the exp, iss, and aud claims before trusting any claim in the payload.
What's the difference between JWT, JWS, and JWE?
JWT is the claims format — a JSON payload with fields like sub and exp. JWS (JSON Web Signature) wraps it with a signature: anyone can read the payload, but tampering is detectable. JWE (JSON Web Encryption) actually encrypts the payload so it cannot be read without the key. Almost every JWT you meet in the wild is a JWS, which is why Base64URL decoding reveals its contents — encoding is not encryption.
What is the alg: none attack?
The JWT spec allows alg: "none" for unsecured tokens. In the attack, someone takes a valid token, changes the header algorithm to none, strips the signature, and replays it — early libraries accepted the forged token as verified. Modern libraries reject none by default, but the lesson stands: servers should pin an explicit allowlist of expected algorithms instead of trusting whatever the token header claims.
Why is my token rejected even though it decodes fine here?
Decoding only proves the token is well-formed Base64URL JSON. Servers additionally check the signature, expiry (exp), not-before (nbf), issuer (iss), and audience (aud) — and clock skew of even a minute can make a fresh token look premature or expired. For a deeper automated review of a token's claims and configuration, try the JWT Security Checker on this site.