TOTP Generator

Generating a 2FA Code from a Base32 Secret

1. Paste the base32 secret into the input. Most sites display it on the 2FA setup page under "Can\'t scan the QR code?" or "Manual entry". Valid base32 uses only A-Z and 2-7; padding = is optional.
2. Watch the code appear. The tool computes the current 6-digit TOTP and displays it with a 30-second countdown ring that refreshes the code at each window boundary.
3. Copy the digits by clicking the code itself or the copy button. The code is valid for the remaining seconds on the ring plus one window on either side on most servers.
4. Enter the code into the login field of the service. If it is rejected, check your device clock - TOTP is time-sensitive down to the second.
5. Wait 30 seconds for a fresh code if the current one is close to expiry. Do not type a code that has less than 3 seconds remaining; network latency alone can push it past the window.

Inside the 30-Second Magic: HOTP, TOTP, HMAC-SHA-1

TOTP is specified in RFC 6238 and builds on HOTP (RFC 4226). The algorithm: TOTP = Truncate(HMAC-SHA-1(K, T)) where K is the base32-decoded secret and T = floor((currentUnixTime - T0) / X), with T0 = 0 and X = 30 seconds. The tool decodes base32 into the HMAC key, packs the time window as an 8-byte big-endian integer, computes HMAC-SHA-1 via crypto.subtle.sign, then applies dynamic truncation (RFC 4226 section 5.3): low 4 bits of the last byte as offset, read 4 bytes there, mask the top bit, modulo 10^6. Google Authenticator, Authy, Microsoft Authenticator all use these exact defaults.

When You Reach for a Standalone TOTP Tool

• Testing a freshly provisioned 2FA integration during development, where you have the secret but do not want to pollute your personal authenticator with test entries.
• Recovering access after losing your phone when you saved the base32 secret in a password manager rather than only the QR code.
• Debugging why your users\' codes are being rejected: paste the same secret your backend stores and check whether it matches Google Authenticator.
• Automating 2FA in a CI pipeline for end-to-end tests against a staging environment where pure-JavaScript test code needs to log in.
• Building a custom authenticator app and wanting a known-good reference to validate your TOTP implementation against.
• Generating a 2FA code on a desktop when your phone is out of reach, using the secret backed up to a password manager.

Clock Drift, Base32 Padding, and Secret Storage Pitfalls

The most common TOTP failure is clock drift. If your clock is more than 30 seconds off wall time, codes are rejected. Servers typically accept plus/minus one window tolerance (RFC 6238 section 5.2), so up to a minute of drift survives; beyond that, sync with NTP. Second pitfall: base32 decoding. Copying a secret can introduce lowercase letters, spaces, or digits 0/1 that are not valid base32. The tool strips whitespace and upper-cases before decoding. Third: the secret is bearer-level - treat it like a password, store in a manager, revoke if it leaks. Fourth: some services use non-standard parameters (6 vs 8 digits, 30 vs 60 second windows, SHA-256 instead of SHA-1). This tool implements defaults; if a service uses non-defaults, Google Authenticator also will not work.

Why TOTP Uses HMAC-SHA-1 in 2026

HMAC-SHA-1 remains the TOTP default despite SHA-1 collision attacks because HMAC\'s security does not depend on collision resistance - only on the pseudo-random-function property, which SHA-1 still has. The 2017 SHAttered attack and the 2020 Chosen-Prefix Collision against SHA-1 broke certificate signing, not HMAC. RFC 6238 section 1.2 explicitly notes that HMAC-SHA-256 and HMAC-SHA-512 variants exist and can be requested via otpauth:// URI parameters, but the installed base of Google Authenticator and compatible apps defaults to SHA-1, so most services stick with the default for interoperability. The truncation to 6 digits is deliberate: it limits the tag to around 20 bits of unpredictability per 30-second window, but combined with rate limiting on the server (lockout after 5-10 wrong codes) the effective attacker success rate is roughly one in a million per lockout interval - acceptable because the secret rotates every 30 seconds. Longer codes (7 or 8 digits) add security against online attacks at the cost of user friction; most services chose 6.

TOTP vs Push-based 2FA, WebAuthn, and SMS

TOTP is the middle ground: more secure than SMS (no SS7 interception, no SIM swap), simpler than WebAuthn, more portable than push (works offline). The downside relative to WebAuthn: the base32 secret exposes in plaintext if the server is breached, and TOTP is phishable - the code is typed into an attacker-controlled site just like the password. WebAuthn (FIDO2/passkeys) uses asymmetric crypto and includes the origin domain in the signed challenge, defeating phishing. Ladder from weakest to strongest: SMS OTP (NIST SP 800-63B deprecated for federal use), TOTP, Push 2FA, WebAuthn. For new deployments, offer WebAuthn first and TOTP as recovery; never SMS-only.