How to Check Whether a JWT Has Expired, Without Doing the Epoch Math Yourself

A JWT's expiry lives in the exp claim, and it's a Unix timestamp - seconds since 1 January 1970, not anything readable at a glance. 1755638400 means nothing until it's converted. JWT decoder does that conversion automatically the moment you paste a token, along with two other timing claims most people forget to check. Here's the actual process.

Step 1 - paste the token

Drop the full token - header, payload and signature together, joined by dots - into the text box. There's nothing to configure first: the decode runs about 150ms after you stop typing or pasting, the same debounce every text tool on this site uses so a fast paste doesn't trigger dozens of redundant redraws.

Step 2 - read the Timestamps panel

If the payload carries any of exp, nbf or iat as an actual number, a Timestamps panel appears with each one converted to a real UTC date and a plain status label next to it. Expires shows the exp claim's date, marked (expired) or (currently valid) depending on whether that moment has already passed. Valid from shows nbf ("not before"), marked (not yet valid) if the token's activation time hasn't arrived yet - a real, standard claim that's easy to forget exists, and a token rejected before its stated expiry is sometimes rejected because of this one instead. Issued at shows iat, with no status label, since there's nothing to be valid or expired about a creation timestamp on its own.

Step 3 - trust the label, not your own math

Converting a Unix timestamp by hand means multiplying by 1000 for milliseconds, building a date, and getting the direction of the comparison right - easy enough to get backwards under time pressure, especially with nbf, where "not yet valid" and "expired" are opposite failure modes that a rushed mental check can flip. The tool does that conversion and comparison for you and states the result in plain language, so there's nothing left to double-check by hand.

If no Timestamps panel shows up at all

That means the payload didn't carry a usable exp, nbf or iat - either the token genuinely has none of those claims (not every JWT sets an expiry, even though most production tokens should), or a claim sharing one of those names holds something that isn't a real number, like a string or null. Either way, nothing gets guessed at: the payload's own pretty-printed JSON block still shows the exact value untouched, so you can see for yourself what's actually there instead of the tool inventing a timestamp that doesn't exist.

Reading the header and signature at the same time

The Header block above the Timestamps panel usually decodes to something short - typically just alg (the signing algorithm, commonly HS256 or RS256) and typ. Worth a glance if you're also trying to confirm which algorithm a token was signed with. The Signature block below shows the raw signature segment exactly as received - it's cryptographic bytes, not text, so it's never decoded - and for an unsigned alg: none token it says so plainly rather than showing an empty block with no explanation.

What a valid-looking expiry doesn't tell you

A token can show (currently valid) next to its exp date and still get rejected by a real server, because reading the expiry claim and verifying the signature are two different checks. This tool only does the first - it has no way to confirm the signature was produced by the real signing key, and it never will, because that would mean asking you to paste a secret into a public page. A currently-valid expiry combined with a server-side rejection almost always means the problem sits somewhere else: a wrong signing key, a wrong audience or issuer claim, or a permission check on a claim the expiry has nothing to do with.

Working with a large or unusual token

The tool handles input up to 50,000 characters comfortably - real JWTs are almost always well under 8KB, since many servers and proxies reject anything larger outright, so this is generous headroom rather than a tight limit. In this project's own measurement, decoding and formatting a 64,148-character synthetic token - well past that limit - took 0.6-1.8ms across five trials, so there's no meaningful delay to notice even on a token carrying an unusually large set of custom claims.

For the broader reason APIs use expiring, signed tokens in the first place, see the background. If a token decodes fine, isn't expired, and still gets rejected, this guide covers what else to check. Or paste a token now.