JWT Timeline Visualizer

How to Use the JWT Timeline Visualizer

1. Paste your JWT into the text area. It should be in the standard header.payload.signature format.
2. The timeline appears instantly — a bar shows issued-at (blue), not-before (amber), expiry (red), and the current time (green).
3. Check the validity banner — it shows whether the token is currently valid, expired, or not yet active.
4. Switch to "All Claims" to see the full decoded JSON payload with all registered and custom claims.
5. Switch to "Raw Parts" to see the decoded header, payload, and the raw signature string.

Understanding JWT Timestamps

JWTs use Unix timestamps (seconds since January 1, 1970 UTC) for all time-related claims. The three standard time claims defined in RFC 7519 are:

iat — Issued At

The iat claim records the exact moment the token was minted. It is useful for implementing token age checks on the server — for example, rejecting any token older than 30 days regardless of whether it has expired. The iat is set by the issuer (authorization server) at token creation time and cannot be changed without invalidating the signature.

nbf — Not Before

The nbf claim specifies a future time before which the token must not be accepted. This is rarely used in typical web authentication but is valuable in scenarios where you create a token in advance and want it to become active at a specific future time. For example, a token for a scheduled job that runs in 10 minutes could have an nbf set to now + 10 minutes. Servers implementing nbf checks must reject tokens presented before this time.

exp — Expiration Time

The exp claim is by far the most commonly used time claim. It defines when the token ceases to be valid. Once the current time exceeds exp, the token is expired and any compliant server must reject it. Short-lived access tokens (15 minutes to 1 hour) are best practice for security — if a token is stolen, its usefulness to an attacker is time-limited. Refresh tokens typically have a much longer expiry (days to weeks).

Clock Skew

Because different servers may have slightly different clocks, RFC 7519 recommends allowing a few minutes of clock skew when evaluating nbf and exp. Most JWT libraries implement a configurable clockTolerance or leeway parameter (typically 30–300 seconds) to account for this. This tool uses your local browser clock, which may differ slightly from the server that issued the token.

Token Validity Windows

A token is fully valid when: (1) the current time is at or after nbf (if present), AND (2) the current time is before exp (if present). If neither claim is present, the token has no time-based constraints and must be validated by other means (such as a revocation list or session database). This tool visualizes all three timestamps on a single timeline bar, making it easy to see at a glance how long a token has been alive, how long it was valid for, and whether it is currently active.

Security Best Practices for JWT Expiry

• Keep access tokens short-lived — 15 minutes is common for OAuth 2.0 access tokens
• Use refresh tokens for longer sessions — and rotate them on each use (refresh token rotation)
• Never store tokens in localStorage for sensitive apps — use httpOnly cookies to prevent XSS theft
• Implement token revocation — a short expiry alone is not sufficient; maintain a blocklist for compromised tokens
• Always validate the signature — never trust claims from a decoded payload without signature verification on your server