JWT decoder
Read a JWT header and payload locally. The signature is not checked.
Runs locally in your browser. Nothing is uploaded.
How to read a token
Paste a JSON Web Token. It looks like three segments of base64url separated by dots. The page decodes the first segment as the header and the second as the payload, then pretty-prints both as JSON. A leading “Bearer ” is ignored so you can paste an Authorization header value. If the header has an alg claim, it is shown above the JSON. exp, nbf, and iat are printed as UTC timestamps when they are numbers, and the page says whether exp is already in the past relative to your clock.
The third segment is the signature. It is shown as the original base64url text. It is not checked. Checking a signature needs the secret or the public key, a decision about which algorithms you trust, and a rejection of alg values you did not expect. A decoder that pretended to “verify” without a key would be misleading. Do not treat a successful decode as proof that a caller is signed in. Verification belongs in the service that holds the key.
What you can learn from an unverified payload
You can still learn a lot. The header tells you the algorithm the issuer claimed. The payload tells you the subject, the audience, the expiry, and any custom claims. That is enough to debug a client that is sending the wrong token, to see that a token expired an hour ago, or to confirm that a scope claim is missing. It is not enough to grant access.
Tokens are credentials. Pasting one into a website that uploads the field gives that website the credential. This page decodes in the browser and does not have a backend to receive it. Even so, treat a production access token as a secret: prefer a short-lived token, and avoid leaving it on a shared screen. The JSON formatter is the right place when you already have the payload as JSON and only want it indented. The hash generator is unrelated to JWT signatures. A SHA-256 of the token text is not a verification.
Common questions
Why did decode succeed on a token I forged?
Because anyone can base64url-encode a JSON object and put a dot after it. The signature is what would have caught that, and this tool does not check it. A forged payload still “decodes.”
What about the none algorithm?
If the header says alg is none, or the signature segment is empty, the page still prints the JSON. It does not special-case that token into a trusted state. Services should reject unexpected algorithms. The label on this page stays “not verified.”
The payload is not JSON. What happened?
A JWT header and payload are JSON. If the segment decodes to an array, a string, or garbage, the page reports that. Encrypted JWEs are a different shape and are not decrypted here.
Does the expiry check contact a time server?
No. It compares the exp claim with the clock in your own computer. If that clock is wrong, the “expired” line is wrong by the same amount.