b2KIT

Two-Factor Auth Tester

Generate TOTP codes from a secret key (RFC 6238). Verify codes and test your 2FA setup in real time.

How to Use Two-Factor Auth Tester

  1. 1

    Enter a secret key

    Paste the TOTP secret key or scan a QR code.

  2. 2

    Generate a code

    See the current time-based one-time password generated.

  3. 3

    Verify the code

    Test that the generated code matches your authenticator app.

Tested tool guide Tested browser tools Checked August 16, 2026

What Two-Factor Auth Tester does, with a checked example

An authenticator app is a small clock, not a vault: the six-digit code it shows is a deterministic calculation from two inputs, the shared secret and the current 30-second time window. This tool runs that same RFC 6238 calculation in the browser, so you can regenerate codes from a saved secret, check a code from your phone before you rely on it, and diagnose why a code was rejected. The part users find odd: the code has no memory. Anyone holding the secret can reproduce the exact code, and it stops being valid the moment the window rolls over.

Worked example

A concrete input and expected output from the current implementation.

Input

Secret: GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ, with the time field set to Unix time 1111111111 (2005-03-18 01:58:31 UTC), 6 digits, SHA-1, 30-second period

Expected output

050471

GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ is the base32 encoding of "12345678901234567890", the SHA-1 test seed from RFC 6238 Appendix B. The RFC publishes the 8-digit code 14050471 for this instant, and reducing to six digits is exact: 14050471 mod 10^6 = 050471.

How the result is produced

1

Time becomes a counter

The tool divides the current Unix time by the period (30 seconds by default) and uses the whole-number quotient as the HMAC counter. It computes HMAC-SHA1 with the base32-decoded secret as the key, truncates the hash to 31 bits, and takes that value modulo 10^6 to get the code, padded to six digits with leading zeros.

2

Verification and clock skew

Verification compares the entered code with the code computed for the current window, so device clock accuracy matters. If the phone that generated the code is more than about 30 seconds off from the browser's time, a correct code will fail; syncing the phone's clock is the usual fix. A passing code proves only that it was derived from the same secret, not that a particular account is authorized.

Good uses

  • You replaced your phone or switched authenticator apps and want proof the new setup works before disabling the old one: generate a code here from the same secret and confirm it matches the app at the same moment.
  • Your phone is lost, in repair, or offline and a login demands a 2FA code: regenerate it from the secret stored in your password manager or printed recovery sheet.
  • A service keeps rejecting your codes: compare the code here with the app's code, then check the secret string, the device clock, and the digit count the service enrolled.

Limits and checks

  • A code is valid only within its 30-second window. Generation uses the current window, so the answer changes at every boundary: a code that verified a minute ago will not verify now, and a code typed just as the window ends can fail through no fault of the secret.
  • The secret is case-insensitive base32, limited to the letters A-Z and the digits 2-7. A one-character typo, a stray space, or pasting the '=' padding produces a different secret and therefore a different code, so copy the string rather than retyping it.
  • Settings must match the enrollment: RFC 6238 test vectors and some sites use 8 digits or SHA-256 instead of the 6-digit SHA-1 default, and periods of 60 seconds exist. An account verified with the wrong setting fails even with the correct secret.

Common questions

Does this tool upload my secret or send codes anywhere?

No. The calculation runs entirely in the browser on your machine, and nothing is sent to a server. Even so, treat the secret as the credential it is: by itself it lets anyone generate your codes, so paste it only into tools you trust, and rotate it if it is ever exposed.

Why does my app's code not match the one this tool shows right now?

Most likely causes, in order: you entered the secret with a typo or extra space, the two are in different 30-second windows (wait for the code to rotate), or the account was enrolled with different settings such as SHA-256 or 8-digit codes. A phone clock more than about half a minute off also produces mismatches.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools