JWT Decoder
Signature is not verified — decode-only tool
- Paste the complete token, with its three parts separated by dots.
- The header and payload appear already formatted as readable JSON.
- If the token carries exp and iat, the expiry and issue dates are converted to readable form, and the expired or valid status is computed.
A JWT is made of header, payload and signature, joined by dots. The first two are JSON encoded in Base64URL, a variant of Base64 that swaps + for -, / for _, and drops the = padding.
The header describes the signing algorithm, normally in the alg field, and the token type.
The payload carries the claims: who issued it (iss), who it is for (aud), who the subject is (sub), when it expires (exp) and when it was issued (iat), alongside your application specific fields.
The signature is what guarantees header and payload were not altered. It is produced with a key only the issuer holds.
This tool decodes but does not verify the signature, and the interface says so when it displays the token.
The difference matters: anyone can read and even rewrite a JWT payload. What prevents fraud is verifying the signature on the server, with the secret key or the matching public key. Without that step, a tampered token passes.
Verifying a signature requires the key. Since the key must never leave your server, no web tool that does not hold it can perform that check, including this one.
Base64 is encoding, not encryption. Anyone who intercepts the token reads the payload without needing any key.
So never put a password, another service token, a card number or any sensitive data inside a JWT. Put an identifier and fetch the rest on the server.
The token you paste here never leaves your browser: decoding happens locally and nothing is sent or logged.
Frequently asked questions
Because verifying requires the issuer secret key, which should never leave the server. A web tool asking for your key would be a security risk, not a convenience.
Decoding runs in your browser and nothing is transmitted. Even so, treat any production token as a live credential: if it has been exposed elsewhere, revoke it.
The exp field is compared against your computer clock. If it runs fast or slow, the result differs from what the server computes. Some servers also allow a small time tolerance.
Editing is trivial, but the resulting token will be rejected by any server that verifies the signature. Without the key there is no way to produce a valid one.
In a traditional JWT the content is only encoded and stays readable. In JWE it is actually encrypted, requiring a key to read. If the data must stay hidden, a signed JWT is the wrong tool.