Decode a JSON Web Token
Paste a JWT to see its header and payload as formatted JSON, with the time claims converted to readable dates and an at-a-glance expiry check. Decoding happens entirely in your browser, so the token is never transmitted. The signature is displayed but deliberately not verified — that requires the issuer key and belongs on your server.
How to use the JWT Decoder
- Paste the token — a leading "Bearer " and any stray line breaks are ignored.
- Read the header and payload as formatted JSON.
- Check the claims table for issued-at, not-before and expiry times.
- Use an expired or test token; never paste a live production token into any website.
The three parts of a token
A JSON Web Token is three Base64url-encoded segments joined by full stops: header.payload.signature. The header names the signing algorithm and, optionally, a key id (kid) telling the verifier which public key to use. The payload holds the claims — the actual data. The signature is computed over the first two parts with a secret or private key. The first two parts are encoded, not encrypted: anyone holding the token can read every claim, which is why a JWT must never contain a password, a card number or anything else confidential.
Decoding is not verifying
Reversing Base64url tells you what a token says. It tells you nothing about whether the claims are genuine, because anyone can craft a token with any payload they like. Verification means recomputing the signature with the issuer key and confirming it matches, then checking the algorithm is the one you expect, the issuer and audience are yours, and the token is inside its validity window. A well-known attack sets alg to none or swaps RS256 for HS256 so the public key is used as an HMAC secret; libraries defend against this only if you pin the expected algorithm.
Registered claims
| Claim | Meaning |
|---|---|
iss | Issuer — who minted the token |
sub | Subject — usually the user id |
aud | Audience — the service meant to accept it |
exp | Expiry, in seconds since 1970 (not milliseconds) |
nbf | Not valid before this time |
iat | Issued at |
jti | Unique token id, used to revoke a single token |
Expiry in practice
All three time claims are NumericDate values: seconds since the Unix epoch, not milliseconds. A token whose exp is thirteen digits long is a bug — it will appear to expire in the year 50,000. Verifiers normally allow a small clock skew of 30 to 60 seconds; a token that "expires immediately" in one environment is very often an unsynchronised server clock rather than a code fault.
Why the token stays in your browser
Pasting a live access token into an online decoder hands it to whoever runs that site until it expires. This page decodes locally with no network request, but the safe habit is universal: decode expired tokens, or redact the signature first. If a production token has already been pasted somewhere, rotate the signing key and invalidate the session.
Frequently asked questions
Does this tool check the signature?
No, and no browser tool can without your signing key. Decoding only reverses Base64url. Verify tokens server-side with the issuer key and a pinned algorithm.
Is my token sent to a server?
No. The whole decode runs in your browser with no network request. Even so, prefer test or expired tokens.
Why does my token show as expired when the service accepts it?
Check whether exp is in seconds; milliseconds are a common mistake. Otherwise it is usually clock skew between your device and the issuer.
Can I edit a claim and re-sign the token here?
No. Changing a claim invalidates the signature, and re-signing needs the secret or private key, which should never leave your server.
Privacy
This tool runs entirely inside your browser using WebAssembly and the Canvas/File APIs. Your files are never uploaded to ToolFlint or any third party; you can verify this in your browser's network tab or by switching to airplane mode after the page loads. Read how we process files.
Last updated 2026-09-23.