Skip to content
ToolBoxGenie

JWT Decoder

Developer Tools · Added 12 August 2026

Paste a JSON Web Token and read what is actually inside it: the signing algorithm, the claims, and whether it is still within its validity window. The token is decoded in this tab and never leaves your browser — which matters, because a JWT is a credential.

A leading Bearer is ignored, so you can paste an Authorization header straight in. Decoding happens in this tab — the token is never sent anywhere.

How to use the jwt decoder

  1. 1Paste the token into the box. A leading 'Bearer ' is ignored, so an Authorization header value works as-is.
  2. 2Read the status strip: it says whether the token is inside its window, expired, or not valid yet, and by how much.
  3. 3Check the header for the algorithm and the key id — those tell you which key the issuer expects you to verify against.
  4. 4Work through the claims table. Registered claims such as iss, aud and exp carry a note explaining what each one governs.
  5. 5Use Copy on the payload if you want the JSON somewhere else, such as a bug report.

Examples

An access token that is still valid

Input
A token whose exp is two hours from now
Result
Status: within its validity window · Expires in 2 hours

The exp claim is seconds since the Unix epoch; the decoder expands it to a readable UTC time.

Diagnosing a 401

Input
The token your API keeps rejecting
Result
Status: expired 20 minutes ago

By far the most common cause of a token that 'worked a minute ago'. The next check is the aud claim.

A token with alg set to none

Input
A token whose header reads {"alg":"none"}
Result
Decoded, with a warning that the token claims to need no signature at all

Any server that accepts alg:none is trusting whatever the client sent it. This is a real vulnerability class, not a curiosity.

About the jwt decoder

A JWT is encoded, not encrypted

The most persistent misunderstanding about JSON Web Tokens is that the payload is somehow protected. It is not. The middle segment is plain base64url, which is a transport encoding with no key and no secret — anyone holding the token can read every claim in it, which is exactly what this page does.

What the signature provides is integrity, not confidentiality. It lets a server detect that a claim has been altered; it does nothing to stop the holder reading those claims. The practical rule follows directly: never put anything in a JWT payload that you would not be willing to hand to whoever carries the token.

Reading a token when something is broken

When an API starts returning 401, the token is the first place to look and the order is usually the same. Check exp, because expiry accounts for most of it. Then check aud — a token minted for one service and presented to another is valid and still correctly refused. Then iss, in case a staging issuer has crept into a production configuration.

The header matters too. The alg and kid fields tell the verifier which key to use, and a mismatch there produces a signature failure that looks identical to a forged token from the outside. Reading kid off the token and comparing it against the keys the issuer publishes resolves that ambiguity in seconds.

Frequently asked questions

Does this verify the signature?
No, and no web page honestly can. Verification needs the issuer's shared secret or public key, and pasting a signing secret into a website is exactly the thing you should never do. This tool decodes the base64url segments so you can read the claims; treat everything it shows as an assertion, not as proof.
Is it safe to paste a real token here?
The decoding happens entirely in this browser tab — there is no upload and no server involved, so nothing you paste is transmitted. That said, a JWT is a live credential for as long as it is valid. The safe habit anywhere is to use expired or test tokens when you can, and to treat any token you have pasted into any tool as one you might rotate.
Why is my token rejected as not a JWT?
A JWS has three dot-separated segments. Five segments means it is a JWE, whose payload is encrypted rather than merely encoded, so it cannot be read without the recipient's key. Anything else is usually a truncated copy-paste, a stray line break, or a URL-encoded token that needs decoding first.
What is the difference between exp, nbf and iat?
iat records when the token was issued, nbf is the earliest moment it may be accepted, and exp is the moment it must stop being accepted. All three are NumericDate values — seconds since the Unix epoch, not milliseconds. Sending milliseconds by mistake produces tokens that appear to expire tens of thousands of years from now.

Related tools