JWT Decoder & Verifier
Paste a JSON Web Token and read it the way your server should: header and payload decoded to readable JSON, the time claims drawn as a timeline — issued, valid from, expires, expired — and, for HS256, HS384 and HS512, a real signature verification against a secret you supply. Everything happens in your browser. A token is a credential, and credentials do not get pasted into logged AI chats or strangers’ servers on this site.
What a token is, and what decoding proves
A JWT is three Base64URL segments joined by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two. The middle segment — the one everyone wants to read — is an encoding, not an encryption: the Base64 decoder opens it with no key at all, which is why a token must never carry anything you would not print on a poster. What the signature adds is provenance: edit one claim and the HMAC no longer matches, provided the verifier actually checks — the failures that fill incident reports are servers that decoded and trusted without verifying, libraries that let the token choose its own algorithm, and "none" tokens accepted as gospel. This page mirrors the honest workflow: decode and read everything, read the claim timeline against the clock (an exp in the past is a dead token no matter how valid the signature), heed the algorithm warnings, and only then verify — locally, with the secret staying in the same browser tab as the token. If the secret you are debugging with came from a config file, the .env validator checks that file without transmitting it either; the flagship article, never let a chatbot do your secrets, explains why the whole family of jobs moved into the browser.
Frequently asked questions
Is it safe to paste a production token here?
It is the safest place online to do it, and the reason this tool exists. Decoding happens in your browser, in this page’s code: the token is never transmitted, stored or logged. Compare the alternatives people actually use — AI chats, which retain the conversation on a third-party’s servers, and "online JWT decoders" whose server sees whatever you paste. A token is a live credential until it expires; anywhere it is pasted, it can be replayed from. Here, it goes nowhere — the same local-only rule as the .env validator.
If anyone can decode a JWT, why isn’t that a security hole?
Because decoding was never the protection. A JWT is a signed statement, not an encrypted one: the payload is Base64URL — an encoding, readable by anyone holding the token — and the security lives in the signature, which proves the statement was issued by whoever holds the key and has not been altered. The classic disaster is a developer treating the payload as secret, or a server failing to verify the signature so a hand-edited payload sails through. The article Base64 is not encryption covers the encoding confusion underneath both.
Why can you verify HS256 here but not my RS256 token?
HS256 is symmetric: one shared secret both signs and verifies, so a secret you type can be checked locally with HMAC. RS256 is asymmetric: it is signed with a private key and verified with the matching public key, which this page would have to ask you for — and a page that invites key pastes teaches a habit that ends in a leaked private key. Verify RS256 tokens with the issuer’s published JWKS in your own code or tooling, and never paste a private key into any website or chat, including this one.
What does "alg: none" mean and why the red warning?
It means the token declares that it is unsigned — and a server that honours that declaration accepts any payload from anyone, no key required. It was a real, repeated vulnerability class: libraries that trusted the token’s own alg field could be handed a "none" token with an admin payload. The warning is loud because the correct response is loud: a none token is unauthenticated data, and any system accepting one has an authentication bypass by design.
The signature checks out — am I done?
You have proved the token was minted by a holder of the secret and its contents are unaltered. You have not proved it is meant for you (check the aud claim), that it is current (the timeline above shows exp and nbf), or that the secret itself is strong — HS256 with a guessable secret like "secret" falls to offline brute force, after which anyone can mint tokens your check will bless. Verification is one line of the audit, not the whole audit.