JWT Decoder
Split a three-part token into header algorithm, payload claims and expiry at a glance. Decode only — no signature verification.
>_ USAGE GUIDE
Paste a three-part JWT and it splits instantly into Header (the signing algorithm), Payload (every claim), and the raw signature. Time claims such as exp, iat and nbf are shown in dual form — readable local time plus a relative hint — and expired entries are highlighted in red.
This tool also supports local signature verification: paste the shared secret for the HS256/384/512 family, or the public key for the RS/PS/ES families (PEM or JWK, auto-detected), and the browser verifies the signature on your machine, clearly distinguishing "invalid signature" from "malformed key". Edit & re-encode is supported too: modify the payload and regenerate the token — HS* re-signs with the key you entered, while RS*/ES*/PS* only re-encode the base64 segments (the tool deliberately avoids inviting private keys).
- Paste the token: the three parts are separated and displayed immediately
- Read the claims: expiry and issued-at times appear in your local time zone with an expired/not-expired indication
- Verify locally (optional): paste the secret or public key and get a green/red verdict within the browser
- Re-encode if needed: edit the payload JSON and click Re-encode for a fresh token
Verification and decoding run entirely locally; keys and tokens never leave your device. Still, avoid pasting real long-lived production tokens — test tokens do the job.
>_ FAQ
Q1 · What are the three parts of a JWT?
Header — declares the signing algorithm such as HS256; Payload — carries the claims like sub, exp, and iat; Signature — the tamper-proofing part. The first two are only Base64URL encoded, which means anyone can decode and read them; only the signature protects integrity. That is why sensitive plaintext must never go into the payload.
Q2 · Can this tool verify whether a token is valid?
Yes. Paste the signing secret (HS* family) or the public key (RS*/PS*/ES* family, PEM or JWK both work) and the tool verifies the signature locally in your browser: green means the signature is valid, red means it is invalid, and a malformed key gets its own error message. All mainstream algorithms are supported — HS256/384/512, RS256/384/512, PS256/384/512 and ES256/384/512. Note that a valid signature only proves the content matches the key — whether the token was revoked is still your server's call.
Q3 · How do I tell when a JWT expires?
Look at the exp claim in the payload — a Unix timestamp in seconds. This tool converts it to readable local time and adds a relative hint (such as "expires in 3 h") next to exp, nbf and iat; expired entries turn red. When debugging mysterious logouts, check exp first: if it is earlier than the current time, the logout was a normal expiry, and you should inspect the refresh-token logic rather than the login logic.
Q4 · What is an alg=none token, and is it usable?
alg: none means unsigned — anyone can forge the content, making it security-equivalent to plaintext. This tool shows a prominent warning for such tokens and decodes them for display only. Production systems must never accept alg=none tokens (several JWT libraries have had bypass bugs over exactly this); if your backend still accepts them, fix that first.
Q5 · The token has not expired but the API returns 401 — why?
Frequent causes: the server rotated its signing key so old tokens fail verification — the local verification in this tool confirms that instantly; the token was actively revoked (for example after a password change); the endpoint requires a scope or role the token lacks; or a multi-device policy invalidated the session. Verify the payload fields and signature here first to rule out the simple causes, then move to server logs.