TOTP Generator: RFC 6238 Codes, Verified Against Official Test Vectors
Time-based one-time passwords power nearly every app-based two-factor authentication flow. This generator implements the algorithm exactly as specified in RFC 6238 — HMAC over a time counter, dynamically truncated per RFC 4226 — and was verified during development against all five official test vectors from the RFC itself, producing identical codes.
HOTP = dynamic truncation of HMAC(secret, counter) per RFC 4226.
HOTP + Time = TOTP
TOTP is HOTP (HMAC-based One-Time Password) with one specific change: instead of an incrementing counter that both sides track and sync, the counter is derived from the current Unix time divided by the period (usually 30 seconds). Both the client and server compute the same counter independently as long as their clocks are reasonably in sync, which is why authenticator apps don't need any network connection to generate valid codes.
Dynamic Truncation, Not Just 'Take the Last Digits'
The HMAC output is a full-length hash (20 bytes for SHA-1), far longer than a 6-digit code. RFC 4226's dynamic truncation algorithm picks a starting offset from the hash's own last nibble, extracts 4 bytes from that offset, masks off the highest bit (to avoid sign issues), and takes the result modulo 10^digits. This specific procedure — not a simpler truncation — is what every compliant implementation must replicate exactly.
Why the QR Code Uses the otpauth:// Scheme
otpauth://totp/ is the de facto standard URI scheme (originated by Google Authenticator, now universal) for encoding everything an authenticator app needs to set up an account: the secret, issuer name, account label, algorithm, digit count, and period — all in one scannable QR code.
Practical Examples
Verifying Your Own TOTP Implementation
Cross-checking against a known-good generator.
- 1.Use the same base32 secret in both systems
- 2.Compare the 6-digit codes at the same moment
- 3.Codes should match exactly if your implementation is correct
Setting Up a Test Account
Simulating a real 2FA enrollment flow.
- 1.Enter issuer and account name
- 2.Scan the generated QR code with Authy/Google Authenticator
- 3.Confirm the app's code matches this page's code
What This Tool Supports
- SHA-1, SHA-256, SHA-512 algorithms
- 6 or 8-digit codes
- Configurable period: 15-60 seconds
- Live-updating code with countdown
- Scannable QR code: standard otpauth:// URI
Good Use Cases
- Testing a custom TOTP implementation for correctness
- Generating a code from a backup 2FA secret
- Understanding exactly how authenticator apps compute codes
- Demonstrating 2FA setup flows for documentation or QA
Frequently Asked Questions
Is this the same algorithm Google Authenticator uses?
Yes — it implements RFC 6238 (TOTP) built on RFC 4226 (HOTP), the same standard every major authenticator app follows. This implementation was checked against all five official RFC 6238 test vectors and produced byte-for-byte matching codes.
What is the base32 secret?
It's the shared key between you and the service, encoded in base32 (letters A-Z and digits 2-7) — the standard encoding TOTP secrets are displayed and entered in, since it's compact and avoids ambiguous characters like 0/O or 1/I/l.
Can I scan the QR code with a real authenticator app?
Yes — it encodes a standard otpauth://totp/ URI with your secret, issuer, algorithm, digits, and period, the same format services generate when you set up 2FA. Scanning it with Google Authenticator, Authy, or 1Password should produce codes matching what this tool shows.
Why would I use this instead of just scanning a real 2FA QR code?
It's useful for testing and debugging: verifying your own TOTP implementation produces matching codes, understanding how a specific algorithm/digit/period configuration behaves, or generating a code from a secret you already have (e.g., recovering 2FA access using a backup secret) without an authenticator app installed.
Why do most services use SHA-1 instead of SHA-256?
SHA-1's use in HMAC-based TOTP isn't the same security concern as SHA-1's use in digital signatures or certificates — the RFC 6238 construction remains sound. SHA-1 became the de facto default early on and most authenticator apps and services still default to it for backward compatibility, even though SHA-256/512 are also standard-supported options.
Is my secret sent anywhere?
No, code generation and QR rendering both happen entirely in your browser via the Web Crypto API and a local QR library — nothing is transmitted. Still, avoid pasting real production 2FA secrets into any browser tool as a general precaution.