Fundamentals
How TOTP works without sending you a message
Understand the shared secret, time counter, HMAC calculation, and why a six-digit code changes every 30 seconds.
TOTP starts with a shared secret
When you enable app-based two-factor authentication, the service creates a random secret. The QR code on the setup screen normally contains that secret, an account label, the service name, and a few algorithm settings. Scanning the QR code copies this information into your authenticator.
The service keeps its copy of the secret, and your authenticator keeps another copy. The secret is not the six-digit code. It is the long-term material from which every future code can be generated, which is why a screenshot or text copy of a setup QR code must be protected carefully.
Time becomes a moving counter
TOTP divides Unix time into fixed windows, most commonly 30 seconds. Every device in the same window derives the same counter value. The authenticator combines that counter with the secret using HMAC, then converts part of the result into a short decimal code.
The service performs the same calculation during sign-in. If your submitted code matches the expected result for the current or a nearby time window, the service accepts the second factor. Nearby windows are sometimes allowed to account for a small amount of device clock drift.
- The most common algorithm is HMAC-SHA-1.
- Codes usually contain six digits, although eight digits are also defined.
- The standard period is 30 seconds, but some systems use a different interval.
Why no network connection is required
An authenticator does not need to contact the account provider to generate a TOTP code. Once it has the secret, it needs only a sufficiently accurate clock and a standards-compliant calculation. That is why authenticator apps continue working in airplane mode.
A website-based generator can also perform the same calculation locally, but its security depends on the page code and the browser environment. For long-term everyday use, a reputable dedicated authenticator with encrypted backup is generally more convenient. A local web tool is best treated as a focused utility, not as permanent secret storage.
What the code does—and does not—prove
A correct code proves that the person signing in has access to the shared secret at that moment. It does not prove that the sign-in page is genuine. A convincing phishing page can ask for a password and current TOTP code, then relay both to the real service before the code expires.
TOTP is a meaningful improvement over password-only access, but phishing-resistant methods such as passkeys and hardware security keys are stronger where they are supported. The best choice is often to use the strongest method offered by each important account.