Say this as plainly as possible, because it is the single most misunderstood thing about JWTs: decoding is not verification. Anyone, including this tool, can read every claim inside a JWT without knowing the secret or private key that signed it, because the header and payload are only base64url encoded, not encrypted. This jwt decoder shows you what a token claims, not whether those claims are trustworthy. Trusting a token's contents requires verifying its signature against the correct key on your own server, something no browser based tool can safely do for you.
That distinction matters because a JWT payload is readable by anyone who has the token string, full stop. Never put a password, a credit card number or any other secret directly inside a JWT payload expecting it to stay hidden. If a value needs confidentiality, encrypt it separately or keep it out of the token entirely.
What this jwt decoder actually shows you
A JWT is three base64url segments joined by periods: a header describing the signing algorithm and token type, a payload carrying the claims, such as who the token is for and when it expires, and a signature that a server uses to confirm the first two segments have not been tampered with. This jwt decoder splits the token on those periods, base64url decodes the first two segments and parses each one as JSON.
The signature segment is shown too, but only as its raw base64url text. There is no key present in a decoded token, so there is nothing this tool, or any purely client side tool, could check the signature against. Displaying it lets you copy it for use with a separate verification step on your own backend, where the correct secret or public key actually lives.
Reading exp, iat and nbf as real dates
Three claims defined by the JWT specification carry time information as Unix timestamps, which are unreadable as raw numbers. The exp claim is the expiration time, after which the token should be rejected. The iat claim is when the token was issued. The nbf claim, not before, marks a time before which the token must not be accepted yet, useful for tokens that are generated ahead of when they should become valid.
This jwt decoder converts all three into full, human readable dates in your local timezone, and compares exp against the current time to show a plain expired or valid indicator directly next to it. Acting as a jwt expiration checker is often the whole reason people paste a token in, since it answers the single most common question at a glance: has this thing already expired.
- exp past the current time: the token has expired and a server should reject it.
- exp in the future: the token is still within its validity window.
- nbf in the future: the token is not valid yet, even though it may not have expired.
- No exp claim present: the token never expires by design, which is unusual and worth double checking.
Decoding is not verification
This point is worth repeating in its own section because getting it wrong has real security consequences. Verification means cryptographically confirming that the signature segment was produced by the expected signing key over the exact header and payload bytes present in the token. That check requires the secret key, for HMAC based algorithms such as HS256, or the correct public key, for asymmetric algorithms such as RS256 or ES256.
A browser based decoder has no legitimate way to hold that key for you, and even if it did, running the verification client side would let anyone edit the JavaScript and make an invalid token appear valid. Signature verification belongs on a trusted server, using a well maintained JWT library in whatever language your backend is written in, never in a public webpage. Treat every claim shown by this tool as unverified until your server has confirmed the signature.
Why a JWT payload is not encrypted
JWTs are built on base64url encoding, defined by RFC 4648, which is a reversible text representation, not a cipher. There is no key required to reverse it, which means the header and payload of any JWT can be read by literally anyone who obtains the token string, including a browser extension, a proxy, a logging system, or a person who finds it in a URL or a browser history.
This is by design and is not a flaw in the JWT specification. JWTs are meant to carry claims that are safe to be seen by the party holding the token, such as a user identifier or a list of granted permissions, while the signature protects those claims from being altered undetected. If a claim genuinely needs to stay secret from the token holder, the specification defines an encrypted variant called a JWE, which is a different, less common format from the signed JWT this tool decodes.
| Claim | Name | Meaning |
|---|---|---|
| exp | Expiration time | Unix timestamp after which the token must be rejected |
| iat | Issued at | Unix timestamp when the token was created |
| nbf | Not before | Unix timestamp before which the token must not be accepted |
| sub | Subject | Identifier of the user or entity the token is about |
| iss | Issuer | Identifier of the party that issued the token |
How to decode a JWT
- 1
Paste the token
Copy a full JWT, the three base64url segments separated by periods, into the input box.
- 2
Review the header
Check the signing algorithm and token type declared in the first segment.
- 3
Review the payload claims with the jwt claims viewer
See every claim pretty printed in the claims viewer, with exp, iat and nbf shown as readable dates.
- 4
Check the expiry indicator
Confirm at a glance whether the token has already expired based on its exp claim.
Related tools worth bookmarking
Sources and further reading
- RFC 7519: JSON Web Token (JWT)The specification that defines the structure of a JWT and the standard claims such as exp and nbf.rfc-editor.org
- OWASP Cheat Sheet SeriesSecurity guidance on validating JWTs correctly, including common signature verification mistakes.owasp.org
- MDN: Base64Background on the base64url encoding used for the header and payload segments of a JWT.developer.mozilla.org
Frequently asked questions
Common questions about the jwt decoder.
No. Decoding only reads the header and payload, which requires no key at all. Verifying a JWT means cryptographically checking its signature against the correct secret or public key, which this tool cannot and does not do. Always verify a token's signature on a trusted server before relying on any of its claims.
No. A standard signed JWT uses base64url encoding for its header and payload, which is reversible without any key. Anyone holding the token string can read every claim inside it. If information genuinely needs to stay confidential, it should either be left out of the token or carried in an encrypted JWE instead.
exp is the expiration time after which the token should be rejected, iat is when the token was issued, and nbf is a not before time before which the token must not be accepted, even if it has not expired. All three are Unix timestamps, and this decoder converts them into readable local dates automatically.
No. Every step, splitting the token, base64url decoding the segments and parsing the JSON, happens locally in your browser using standard JavaScript. Since JWTs frequently carry live session data, that matters, and you can confirm it yourself by checking the network panel in your browser's developer tools.
The exp claim is compared against your device's current clock in UTC. A token that looks recently issued can still show as expired if its exp claim was set with a very short lifetime, commonly anywhere from a few minutes to an hour for access tokens, or if your device clock is wrong.
No. This tool decodes standard signed JWTs, which have a readable JSON payload. A JWE encrypts its payload and requires the correct decryption key to read at all, which is a fundamentally different process from decoding a signed token's base64url segments.