Set up a secret, scan it into Google Authenticator, Microsoft Authenticator or any other app, and watch every step of RFC 6238 that turns the secret and the clock into the same six digits on both screens. Nothing leaves this page.
Pick the app you will scan with. The page restricts the parameters to what that app is known to handle.
The shared secret is what the server and the phone both keep. It is shown here in Base32, the form authenticator apps accept.
Paste an otpauth://totp/… link from another app or service to load its settings.
Scan this with the app, or type the setup key by hand.
This is what a server does at login: compute the codes around the current time step and accept a match.
Shift this page's clock to see why phones with the wrong time produce rejected codes, and how the acceptance window absorbs small drift.
RFC 6238 is HOTP (RFC 4226) with the counter replaced by the number of whole periods since the Unix epoch.
Each code is valid for one period. Dashed cells are the extra steps the checker above will still accept.
The hashes, HMAC, HOTP and TOTP on this page are implemented in plain JavaScript and checked on load against the published test vectors.
Why the codes match. Both sides hold the same secret and agree on the time. Each computes HMAC(secret, ⌊time ÷ period⌋), cuts four bytes out of the result, and reduces it to the chosen number of digits. Nothing is sent between them.
Why Google and Microsoft are locked to SHA-1, 6 digits, 30 s. That combination is the one every authenticator handles. Some app versions honour other algorithm, digit or period settings in the link and some silently ignore them, which produces codes that never match. Use the Other app option for apps that document full RFC 6238 support.
Clock drift. A phone running more than about one period fast or slow gives codes the server rejects. Turning on automatic network time on the phone fixes nearly every “wrong code” report.
The acceptance window. RFC 6238 recommends accepting at most one step either side of the current one. A real server should also refuse a code that has already been used once.
Secret strength. RFC 4226 requires at least 128 bits and recommends 160. Secrets made here come from the browser's cryptographic random generator.
Using this page for real accounts. It works, but anyone who sees the secret or the QR code can produce your codes forever. Treat the secret like a password.