JWT Time Inspector
Paste any JSON Web Token to instantly see its time claims — iat, exp, and nbf — as human-readable dates with a live expiry countdown and an interactive clock skew simulator.
What are JWT time claims?
A JSON Web Token is a compact string of three dot-separated parts: a header, a payload, and a signature. The payload is a JSON object that can carry any claims the issuer wants — user ID, roles, permissions — but three specific keys are reserved for time: iat (issued at), exp (expiration), and nbf (not before). Each stores a Unix timestamp — whole seconds since January 1, 1970 UTC.
Most tokens you encounter in the wild carry iat and exp. The nbf claim is less common but useful for scheduled access — a token minted now that should not be usable for another five minutes, for example.
Why does a valid token get rejected?
The most common culprit is clock skew— a small difference in current time between the machine that issued the token and the machine verifying it. If the verifier's clock is even 30 seconds ahead of the issuer's clock, a freshly-minted token can appear to have been created in the future and be rejected as suspicious.
This happens often in distributed systems: Kubernetes pods, cloud functions, and microservices each run their own clock, and real-world drift of a few seconds is normal. Production auth servers typically add a grace window of 30–60 seconds when checking exp and nbf to absorb this drift. The Clock Skew Simulator above lets you drag a slider and see exactly how any offset changes the token's validity from the verifying server's perspective.
How long should a JWT be valid?
Shorter lifetimes reduce the window of risk if a token is stolen. A stolen short-lived token becomes worthless quickly; a stolen long-lived token stays dangerous until it expires. The tradeoff is user experience and system complexity — very short tokens require frequent re-authentication or a refresh token mechanism.
- API access tokens: 15 minutes to 1 hour, paired with a longer-lived refresh token (days to weeks).
- Web session tokens: 8–24 hours for most apps, shorter for banking or healthcare.
- One-time tokens (password reset, email verification): 15–30 minutes maximum.
The timeline bar above shows the exp − iat lifetime the issuer intended and how much of it has elapsed — useful for quickly understanding the security posture of a token you are debugging.
Frequently asked questions
What are iat, exp, and nbf in a JWT?
These are the three registered time claims defined in RFC 7519. iat (issued at) is when the token was created. exp (expiration time) is when the token stops being valid — any request after this time should be rejected. nbf (not before) is the earliest moment the token may be used. All three store Unix timestamps: whole seconds since January 1, 1970 UTC.
Why does my JWT get rejected even though it shouldn't be expired yet?
The most common cause is clock skew — a small difference in system time between the server that issued the token and the server that is verifying it. If the verifier's clock is even 30 seconds ahead of the issuer's clock, a freshly-issued token can appear to have been created in the future and get rejected. Use the Clock Skew Simulator on this page to see the exact effect. Most production systems add a 30–60 second grace window to absorb normal drift.
Are my tokens safe to paste here?
Yes. This tool decodes the JWT entirely in your browser using JavaScript — no token data is sent to any server. You can verify this by checking the browser's network panel: no requests are made when you paste a token. That said, avoid pasting production tokens with sensitive user data into any web tool if you can use a test or staging token instead.
What is clock skew and how do I handle it?
Clock skew is the difference in current time reported by two systems. In distributed architectures — microservices, Kubernetes pods, cloud functions — clocks can drift by seconds or even minutes. OAuth 2.0 and OIDC specifications recommend that servers allow a clock skew tolerance of at most a few minutes. In practice, many implementations add a fixed leeway (60 seconds is common) when checking exp and nbf. The slider on this page lets you simulate any offset and see how it affects token validity.
What is a good JWT expiration time?
It depends on the use case. Short-lived access tokens (15 minutes to 1 hour) are safer because a stolen token has a smaller window of misuse — these are typically paired with a longer-lived refresh token. Session tokens for web apps commonly use 8–24 hours. One-time tokens for password resets or email verification should expire in 15–30 minutes. The exp − iat difference shown in the timeline above tells you the lifetime the issuer intended.
Why are JWT timestamps in seconds, not milliseconds?
RFC 7519 specifies that NumericDate values (used by iat, exp, and nbf) are Unix timestamps in whole seconds. This differs from JavaScript's Date.now(), which returns milliseconds. A common bug is setting exp to Date.now() instead of Math.floor(Date.now() / 1000) — the resulting 13-digit value is interpreted as a date roughly 300 years in the future, making the token never expire. If an exp value looks like 1750000000000, that is the milliseconds mistake.
Can this tool verify the JWT signature?
No — this tool focuses on the time dimension of JWTs. Verifying a signature requires the issuer's public key or shared secret, which you should never paste into a web tool. For signature verification use a dedicated library in your own codebase (jsonwebtoken for Node.js, PyJWT for Python, golang-jwt for Go, etc.) or a trusted internal tool.