JWT Decoder splits a JSON Web Token into its header and payload and shows both as readable JSON, including a table of claims with human-readable dates for exp, iat and nbf. It does not verify the signature: reading a token does not tell you it is genuine.
How to read the result
The summary shows alg (the signing algorithm claimed), typ and kid (key identifier) when present, and a status line that says whether exp has passed. The claims table lists every payload field, converting the exp, iat and nbf timestamps to readable dates so an expired or not-yet-valid token is obvious at a glance.
The signature is shown but never checked against a key; a token can decode perfectly and still be forged, expired, or issued for a different audience than the one accepting it.
Defender tips
- Never accept a token with
alg: none, and pin the algorithm your service expects server-side rather than trusting whatever the token header claims; algorithm confusion is a well-known JWT failure. - Check
expandnbfon the server for every request, not just at login; a client can present a stale token regardless of what a UI shows. - Prefer short-lived access tokens with a separate refresh flow over long-lived tokens; a decoded, leaked token is valid for as long as its
expsays, with nothing else stopping it.
FAQ
Does this verify the signature?
No. It only decodes and displays the header and payload, which requires no key. Verifying a signature needs the issuer's public key or shared secret, which this tool never asks for or holds.
Is my token sent anywhere?
No, decoding happens entirely in your browser tab; the token text never leaves the page. Because a token is usually a live credential, it is also never put in the address bar, a share link or the tool's history.
Why does exp show a date in the past?
The token has expired, and the status line says so. A well-built server rejects it on its own clock; this decoder only compares exp with your device's time.