Exact NumericDate boundaries
Check the decoded exp, nbf, and iat claims against the current browser clock. See exact UTC instants and explicit leeway without confusing an unexpired payload with a verified token.
exp 1893456000 UTC "2030-01-01T00:00:00Z" require now < exp + leeway at equality: expired signature: not verified
Time-window checkNot authentication
Expiration, activation, issuance
Paste a three-part compact JWT or Bearer value. The checker decodes the claims set, preserves exact NumericDate text, and evaluates only its time window—never its signature or identity.
Loading the local JWT expiration checker…
The compact token stays in this page.
The exact comparison
RFC 7519 defines exp as a NumericDate after which the JWT must not be accepted for processing. NumericDate is a JSON number of seconds from 1970-01-01T00:00:00Z, ignoring leap seconds. The acceptance condition is strict: the current time must be before the expiration instant. If now == exp, the token is already expired by that claim.
This page implements the boundary as now < exp + leeway. Leeway is an explicit allowance for small clock differences between systems. Its default is zero. With 30 seconds of leeway, an exp at 12:00:00 is treated as passing until just before 12:00:30; at exactly 12:00:30 it is expired. An application should keep leeway small, documented, and consistent.
The checker uses the browser’s current UTC instant when you press the button. It does not infer a timezone from the token because NumericDate is an absolute Unix time. Local timezone affects only how a human might choose to display an instant; it does not change the arithmetic. The table shows an ISO 8601 UTC value to make comparisons portable.
A passing expiration comparison is deliberately labeled “time claims pass,” not “valid JWT.” The payload could have been altered, signed by an untrusted party, produced with a forbidden algorithm, intended for another audience, revoked, replayed, or rejected by application policy. Verify first, then rely on its time claims.
Three related timestamps
All three registered claims use NumericDate, but they answer different questions and do not share one universal validation rule.
exp limits the end of the accepted time window. The consumer requires now < exp, optionally adding a small configured leeway. Missing exp means there is no expiration assertion to check; many applications correctly require the claim anyway.
nbf limits the start of the accepted time window. The consumer requires now >= nbf, optionally subtracting explicit leeway. At exact equality, the not-before constraint passes. A future value may be intentional for a scheduled credential.
iat records when the issuer says the JWT was created. It can support maximum-age or replay policy, but it is not automatically a validity boundary. This checker displays it and reports type problems without turning it alone into pass or fail.
jti is not a time value. A verifier can combine it with server-side state to detect replay or revocation. A unique identifier by itself does not prevent reuse and cannot replace signature, issuer, audience, or time checks.
Boundary table
now >= exp + leewayExpired by expThe asserted upper time boundary fails. A verifier should reject it even if the signature is otherwise correct.now < nbf - leewayBefore nbfThe asserted activation time has not arrived. Wait, correct a clock problem, or investigate an unexpected claim.Time claims passOnly the time assertions pass. Continue with cryptographic verification and every required policy check.No time constraintsThere is no window to evaluate. Enforce whether your application requires expiration or maximum age.IndeterminateDo not guess or convert a string silently. Reject ambiguous input for security decisions.Seconds, not milliseconds
JWT NumericDate values are seconds. A common 10-digit value such as 1893456000 represents 2030-01-01T00:00:00Z. JavaScript Date.now() returns milliseconds, usually 13 digits. Comparing those raw values without converting units makes a fresh token appear expired immediately or pushes dates thousands of years away.
NumericDate may contain a fractional part. For example, 1893456000.5 is half a second after midnight. JSON may also represent the same number with exponent notation. LiveParse normalizes supported exponent forms without converting through floating point and compares the instant with nanosecond arithmetic. More than nine meaningful fractional digits is reported as unsupported rather than rounded invisibly.
Large integers in general JSON payloads can exceed JavaScript’s safe integer limit. The lossless decoder retains their source spelling. Time claims also need a date that the browser can represent for ISO output; a value outside that calendar range is marked out of range. No Number fallback guesses a different instant.
Use the Unix Timestamp Converter when you need to convert an arbitrary seconds, milliseconds, microseconds, or nanoseconds value without a JWT. Use this page when you need the registered-claim semantics and exact exp/nbf boundaries.
Clock-skew policy
Distributed systems may differ by a few seconds even with time synchronization. A short leeway can prevent false rejection at a boundary. Configure it in the verifier, test exact equality, and expose it in diagnostics. Do not add minutes or hours merely to make failures disappear.
If tokens repeatedly fail just before nbf or just after issuance, compare the issuer, verifier, proxy, and client clocks. Correct NTP or platform configuration rather than increasing tolerance indefinitely. Leeway is not a clock-management strategy.
The token producer chooses lifetimes, but the consumer decides acceptance. Document maximum lifetime, required exp, future iat tolerance, and refresh behavior. A decoder cannot infer those application-specific rules from claims alone.
Include test cases at one unit before, exactly at, and one unit after exp and nbf, with and without leeway. Boundary tests catch accidental <=, mixed milliseconds, rounding, and timezone errors better than a token far from expiration.
Unverified input
An attacker can construct a payload with any future exp value and Base64URL-encode it in seconds. The time comparison will pass because it is evaluating the assertion as written. Without a verified signature or MAC from a trusted issuer, there is no reason to believe the assertion. This is why the result remains next to a permanent “signature not verified” warning.
After cryptographic verification, the consumer still needs exact policy. It should allow only expected algorithms, select keys from a trusted configuration, match the issuer, identify itself in the audience, enforce required claims, and consider token type, subject, tenant, scope, nonce, revocation, replay, and maximum age. Different token kinds should have mutually exclusive validation rules where confusion is possible.
Never use a decoded jku, x5u, or other URL as permission to fetch a key from anywhere. Remote key retrieval needs trusted origins, HTTPS validation, redirect and network controls, caching rules, and key-selection policy. This page performs no remote lookup, and the algorithm label is displayed as untrusted text.
For a practical breakdown of what each stage establishes, read JWT decoding vs verification. Use the full JWT Decoder when header parameters, private claims, duplicate names, and signature bytes are the primary debugging target.
Local time inspection
The compact input, decoded header, claims, and time values stay in the current page while the checker runs. The tool does not submit them to a server-side expiration API, place them in the URL, retain them in browser storage, or contact addresses named in the JOSE header. The downloaded report omits the original compact token.
A bearer access token may grant real access even when you only intend to inspect its expiration. Prefer a synthetic or redacted token. Avoid pasting production credentials into shared computers, screen recordings, chat windows, browser extensions you do not trust, or clipboard tools with cloud synchronization. Clear the input when you finish.
The normal page request and static assets still travel over the web, while token calculation is local. Device software can have independent access to memory, screen, keyboard, files, or clipboard. Review the privacy page for those boundaries and follow your organization’s credential-handling and revocation procedures.
Questions answered
Decode the payload, locate the numeric exp claim, interpret it as Unix seconds, and compare the current UTC instant. The time window passes only while now < exp + explicit leeway. Verify the signature and trusted issuer before relying on the claim.
Yes. The current time must be strictly before exp. Equality is expired. This checker uses that exact boundary and applies configured leeway before making the comparison.
The result says there are no expiration or not-before constraints when both exp and nbf are absent. That does not grant unlimited lifetime. A secure application can require exp, enforce maximum token age, or use session and revocation state.
No. It means only that the decoded expiration assertion has not reached its boundary. A modified, unsigned, wrongly signed, revoked, wrong-audience, or unauthorized token can contain a future value. Read decode vs verify.
Use the smallest documented allowance justified by measured clock differences. RFC 7519 permits a small leeway, often only a few minutes at most, but your architecture should define the actual value. This page defaults to zero and never hides a tolerance.
Yes. NumericDate may be non-integer. LiveParse preserves fractional values through nanoseconds and supports exact normalizable exponent notation. More than nine meaningful fractional digits is reported as unsupported instead of rounded.
You may be reading milliseconds as seconds. JWT NumericDate uses seconds, while many JavaScript logs and APIs use milliseconds. A contemporary seconds value is often 10 digits; a millisecond value is often 13. Use the Unix converter to diagnose the source unit.
No. Decoding and time comparison run in the current browser tab. The input is not sent to a conversion endpoint, saved by the tool, placed in the URL, or used to fetch a remote key. Device and clipboard risks remain separate; see privacy.
Yes. “Expiry” and “expiration” describe the same exp boundary in this context. The checker also shows nbf and iat, but it never treats a passing time window as signature verification or complete token validity.