TOTP Time Window Calculator
Time-based one-time passwords (TOTP) rotate on a fixed clock. RFC 6238 defines the time counter that drives this rotation as the number of fixed-length time steps elapsed since a start epoch. This calculator takes a Unix timestamp, a start epoch, and a step size and returns the current counter value, the seconds remaining before the code changes, and the validation window a server should accept to tolerate clock skew. It does not handle secret keys or generate codes; it computes only the RFC 6238 timing parameters.
TOTP timing formula
T = floor( (now - T0) / X )
seconds left = X - ((now - T0) mod X)
accepted counters = (2 * skew) + 1
accepted window = accepted counters * X
now is the current Unix time in seconds, T0 the start epoch (0 for the Unix epoch), X the time step, and skew the number of steps a validator accepts on each side. The counter T is the integer fed into the HOTP function. The accepted window is how long any given code remains valid across all tolerated steps.
Worked example
With now = 1,700,000,000, T0 = 0, X = 30: T = floor(1,700,000,000 / 30) = 56,666,666. The seconds elapsed in the current step are 1,700,000,000 mod 30 = 20, so 10 seconds remain. With a skew of 1, the validator accepts 3 counters (56,666,665 through 56,666,667), an accepted window of 90 seconds.
TOTP windows: frequently asked questions
How is the TOTP counter calculated?
RFC 6238 defines the TOTP time counter as T = floor((Current Unix Time - T0) / X), where T0 is the start epoch (default 0, the Unix epoch) and X is the time step in seconds (default 30). The counter T is the value fed into the underlying HOTP function to produce the one-time code. Every X seconds the counter increments and a new code is generated.
What is the default TOTP time step?
RFC 6238 recommends a default time step X of 30 seconds. This means a new code is generated every 30 seconds. Some services use 60 seconds. A shorter step is more secure against replay but gives the user less time to type the code.
What is the validation window or skew?
Because the user's clock and the server's clock can drift, validators accept codes from a few adjacent time steps. RFC 6238 suggests accepting at most one step backward and forward. With a skew of 1 step at 30 seconds, the total acceptance window is 3 steps, or 90 seconds.
Does this calculator generate actual codes?
No. It computes the timing parameters defined in RFC 6238: the current counter value, seconds remaining before the code rotates, and the size of the validation window. It does not take a secret key or produce the six-digit code, since that requires the shared secret.
Sources and method
- RFC 6238, "TOTP: Time-Based One-Time Password Algorithm," IETF, which defines the time counter T = floor((Current Unix Time - T0) / X) and the default 30-second step.
- The timing arithmetic is a fixed definition; this tool computes it directly from the parameters you enter.
Reviewed by the CalculatorHub team, edited by James Graham, 19 June 2026. See our methodology.