What the JWT Expiry Checker Does
The JWT Expiry Checker answers one question precisely: how long does this token have left? Paste a JWT and run the transform — no options, no keys — and the output panel prints the token's exp claim as an ISO timestamp, the current time on the same scale, and a verdict line: ✓ valid for 2d 14h 3m 21s or ✗ expired 6h 12m 40s ago. The countdown is computed down to the second, in your browser, at the moment you run it.
The tool does exactly one job, and its boundaries are worth knowing. It reads only the exp claim in the payload — it does not evaluate nbf (not-before), does not display iat (issued-at), and does not touch the signature. A token with no exp at all is reported honestly: This JWT has no exp claim. That is a finding, not an error — plenty of long-lived tokens legitimately omit expiry, and knowing which ones do is itself useful.
Use it when a binary expired/valid answer is not enough. The
JWT Validator tells you
that a token expired; this tool tells you
by how much and
when it will expire, which is what you need when debugging refresh windows, clock-skew tolerance, or a session that dies mid-task.
How the JWT Expiry Checker Works
The mechanism is deliberately simple. The tool splits the token on dots, Base64Url-decodes the second segment, and parses it as JSON. It then looks for the exp claim — a number in epoch seconds, as the JWT standard requires. No exp, and the tool stops there with its honest no-expiry report.
With exp in hand, the arithmetic is a pair of conversions. The claim is multiplied by 1000 to reach JavaScript's millisecond epoch and formatted as an ISO 8601 timestamp. The difference exp − now decides the verdict: positive means valid, negative means expired. The duration is then decomposed into days, hours, minutes, and seconds — each unit included only when non-zero, so 90 minutes renders as 1h 30m rather than 0d 1h 90m 0s.
Two properties of the output deserve attention. First, the comparison clock is your browser's — the tool compares against the machine running the page, not any server. If your system clock is off by minutes, the verdict is off by minutes, which matters when you are using the tool to debug clock-skew complaints. Second, the verdict is a snapshot: a token valid for 30 seconds will show expired on the next run. The tool does not count down live; run it again for the current value.
What the tool deliberately does not do is verify anything. The signature is never examined, so the expiry it reports belongs to whatever claims the payload carries — signed or forged alike. It also does not apply the leeway margins production libraries use; servers commonly tolerate 30–60 seconds of clock skew around expiry, so a token this tool reports as just-expired may still be accepted by your backend, and one reported with 5 seconds left may not be.
Using the JWT Expiry Checker
- Step 1 — Paste the complete token. The full three-segment string from your request headers, logs, or storage. Only the payload segment is decoded, but pasting the whole token keeps the workflow identical to the other JWT tools.
- Step 2 — Run the transform. There are no options. An empty input produces empty output; a token without
exp produces the no-expiry message with an info line confirming it. - Step 3 — Read the three lines.
Expires is the claim's absolute time; Now is your browser's current time in the same format; the blank line separates the data from the verdict. The verdict always states the direction explicitly — valid for or expired ... ago — so there is no sign ambiguity. - Step 4 — Re-run for a live answer. The report is a snapshot of one instant. When you need the current margin — before starting a long operation with a short-lived token, for instance — run it again rather than subtracting in your head.
- Step 5 — Investigate a no-expiry finding. If a token genuinely has no
exp, check how your issuer configures lifetimes and whether revocation exists elsewhere. The JWT Decoder shows the full payload when you want to see what other lifetime claims are present.
Common Use Cases
Debugging refresh-window logic. Most clients refresh a token shortly before expiry, and bugs there produce symptoms like "works, then fails randomly." Checking a real token shows the actual margin your client has to work with, in seconds, against the expiry your server actually issues.
Correlating failures with timestamps. When logs show a request failing at 14:32:07, a token that this tool shows expired at 14:32:04 turns a mystery into a timeline. The absolute Expires line exists precisely for this correlation.
Sanity-checking issued lifetimes. Paste a freshly minted token and see exactly how long your auth service says it lives. Teams are routinely surprised — configured ten minutes can be configured-ten-minutes, or something else entirely if a default crept in.
Field-checking tokens before long operations. Before kicking off a batch job with a bearer token, confirm the margin covers the job. Ten minutes of nominal validity is not ten minutes of remaining validity.
Demonstrating expiry to non-specialists. The three-line output — absolute expiry, now, verdict — is legible without JWT knowledge, which makes it useful in incident write-ups and reviews.
Worked Example
Take this token, whose payload carries a single exp claim — epoch 1700000000, which is 2023-11-14T22:13:20Z:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEwNDIiLCJleHAiOjE3MDAwMDAwMDB9.Zm9vYmFy
Run the transform any time after that instant and the output reads:
Expires: 2023-11-14T22:13:20.000Z
Now: 2026-09-24T10:00:00.000Z
Status: ✗ expired 24922d 11h 46m 40s ago
The duration decomposition is doing its job: nearly 2.8 years of expiry renders as a compact day/hour/second stack rather than an unparseable millisecond count. The signature segment here is a placeholder — the tool never reads it, which is worth internalising: this token's claims report perfectly despite the signature being meaningless. Expiry checking is claim reading, not authentication.
Two contrasts complete the picture. A payload of {"sub":"user-1042"} with no exp returns the no-expiry message instead of a verdict. And a token with exp a week in the future shows the same report shape with ✓ valid for 6d 23h ... — the direction flips in the status line, nothing else changes.
Tips and Common Mistakes
- The clock is your browser's. The
Now line and the verdict both derive from the machine running the page. Cross-check Now against a known-good clock before concluding a token expired "early" — the tool can only be as correct as your system time. - Production servers allow leeway this tool does not. Most JWT libraries apply a 30–60 second skew margin by default. A token reported as expired 10 seconds ago may still verify server-side; treat near-zero margins as ambiguous and re-authenticate.
- No
exp means never-expiring by this claim alone. Some designs rely on server-side revocation instead. The tool's no-expiry message is a prompt to check how such tokens die, not automatically a bug. - The verdict does not consider
nbf. A token can be not-yet-valid and carry a far-future exp; this tool would report the validity window without noticing the token is not active yet. The JWT Validator covers the nbf side. - Epoch units, again.
exp must be seconds. A milliseconds value produces an expiry thousands of years out and a verdict of "valid" that no server will agree with. - Expired does not mean tampered, and valid does not mean authentic. The tool reads claims; it does not verify them. Pair it with the JWT HS256 Verifier when authenticity matters.
Frequently Asked Questions
It says my token has no exp claim — is the token broken?
No. exp is optional in the JWT standard, and some issuers deliberately omit it, relying on server-side revocation or very short transport lifetimes instead. The tool reports what it sees rather than treating absence as failure. If your application expects every token to expire, then a no-expiry finding is worth raising with whoever issues them.Why does the verdict disagree with my server?
Three usual causes: clock skew between your machine and the server (check the Now line against reality), leeway margins (most libraries tolerate 30–60 seconds of skew, so borderline verdicts flip), and cached state (the report is a snapshot; a token near the boundary crosses it between runs). For an authoritative answer, the server's own check wins — it holds the clock that matters.Does it check the not-before (nbf) claim too?
No — the tool evaluates
exp only. A token that is not yet active but has a future expiry will show as valid, which is technically true of its lifetime but misses the activation question. The
JWT Validator reports
nbf violations alongside expiry, so use the two together when both bounds matter.
Can it count down in real time?
No — each run is a single computation of exp − now, not a live timer. Re-running the transform gives a fresh answer at that instant. This is deliberate: the tool has no state, and a countdown that keeps running after you edit the input would quickly lie to you.Is an expired token ever still usable?
By design, no — expiry means the receiving service must reject the token regardless of a valid signature. In practice you will see brief grace from leeway margins, and some legacy systems honour long-lived refresh tokens whose access tokens expired. The correct mental model: expiry is the point after which acceptance is a bug, not a favour.Related Tools
JWT Validator adds
nbf checks and claim-presence findings to the expiry question this tool answers;
JWT Decoder reveals the full payload behind the claim;
JWT Generator mints tokens with whatever
exp you choose, ideal for building test fixtures with controlled lifetimes; and
JWT HS256 Verifier covers the authenticity half that expiry checking never touches.