User Rating 0.0 ★★★★★

Total Usage 0 times

Category Security

Issuer (Service Name) The company or service name shown in the authenticator app.

Account (Email or Username) The user's email or username for identification.

Secret Key (Base32)

Base32-encoded secret. Click refresh to generate a cryptographically secure key.

QR Error Correction

L (7%) M (15%) Q (25%) H (30%)

Enter issuer and account to generate QR code

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

Misconfigured two-factor authentication is worse than none at all. A wrong algorithm parameter, an incompatible digit count, or a malformed otpauth:// URI will produce QR codes that scan successfully but generate incorrect codes. The user locks themselves out. This tool generates QR codes that encode TOTP URIs per RFC 6238 and the Google Authenticator Key URI format. It uses a cryptographically secure random number generator (CSPRNG) via the Web Crypto API to produce secrets of 160 to 256 bits, Base32-encoded per RFC 4648. The QR matrix is computed locally using a full ISO/IEC 18004 implementation with Reed-Solomon error correction in GF(2⁸). No data leaves your browser.

The tool validates that the issuer and account fields conform to URI-safe encoding rules and that the period T and digit count d fall within ranges supported by major authenticator apps. A live TOTP preview lets you verify the generated code matches your authenticator before deploying it. Note: some authenticator apps silently ignore non-default parameters (SHA-256, 8 digits). Test with your target app first.

Formulas

The TOTP algorithm derives a one-time password from the current Unix timestamp and a shared secret key. The time counter T is computed as:

T = floor(Unix Time − T₀)T_X

The HMAC is computed over this counter value:

HMAC = HMAC-SHA(K, T)

Dynamic truncation extracts a d-digit code:

OTP = Truncate(HMAC) mod 10^d

The otpauth:// URI encodes all parameters into a scannable format:

otpauth://totp/Issuer:Account?secret=K&issuer=Issuer&algorithm=Algo&digits=d&period=T_X

Where K = Base32-encoded shared secret key (RFC 4648). T₀ = Unix epoch (0). T_X = time step in seconds (default 30). d = number of digits (6 or 8). Algo = hash algorithm (SHA1, SHA256, SHA512). The QR code uses ISO/IEC 18004 byte-mode encoding with error correction level M (~15% recovery) and applies the optimal mask pattern selected by minimum penalty score across 8 candidates.

Reference Data

Authenticator App	SHA-1	SHA-256	SHA-512	6 Digits	8 Digits	Custom Period	Notes
Google Authenticator	✅	✅	✅	✅	✅	❌ (30s only)	Ignores period param silently
Authy	✅	✅	✅	✅	✅	❌	Syncs across devices
Microsoft Authenticator	✅	✅	❌	✅	❌	❌	Enterprise-focused
FreeOTP	✅	✅	✅	✅	✅	✅	Full RFC 6238 support
FreeOTP+	✅	✅	✅	✅	✅	✅	Export/import support
andOTP	✅	✅	✅	✅	✅	✅	Android only, encrypted backups
Aegis Authenticator	✅	✅	✅	✅	✅	✅	Android only, open-source
1Password	✅	✅	✅	✅	✅	✅	Integrated with password manager
Bitwarden	✅	✅	✅	✅	✅	✅	Premium feature
LastPass Authenticator	✅	❌	❌	✅	❌	❌	Basic TOTP only
Duo Mobile	✅	✅	❌	✅	❌	❌	Enterprise push notifications
KeePassXC	✅	✅	✅	✅	✅	✅	Desktop, full RFC support
Steam Guard	✅ (custom)	❌	❌	5 chars	❌	✅ (30s)	Proprietary alphanumeric codes
Yandex Key	✅	❌	❌	✅	✅	❌	PIN-protected

Frequently Asked Questions

Clock skew is the most common cause. TOTP depends on both the server and client agreeing on the current Unix time within a window of ±T_X seconds (default ±30s). If your device clock is off by more than 30 seconds, the time counter T will differ, producing a different HMAC and thus a different OTP. Sync your device clock via NTP (Settings → Date & Time → Automatic). Also verify the algorithm and digit count match - some apps silently default to SHA-1/6-digit regardless of what the URI specifies.

RFC 4226 Section 4 recommends a minimum of 128 bits (16 bytes) and a recommended length of 160 bits (20 bytes) for SHA-1 HMAC. For SHA-256 use 256 bits (32 bytes) and for SHA-512 use 512 bits (64 bytes) to match the hash block size. This tool defaults to 20 bytes (160 bits) for maximum compatibility. Using shorter secrets weakens the HMAC security margin.

Yes, RFC 6238 explicitly supports SHA-256 and SHA-512. However, many popular authenticator apps (Google Authenticator, Microsoft Authenticator) either ignore the algorithm parameter or handle it inconsistently. If you require SHA-256/512, verify your target app supports it. Aegis, FreeOTP, KeePassXC, and 1Password provide full support. For maximum compatibility across all apps, SHA-1 remains the safest choice despite its age - HMAC-SHA1 is not affected by SHA-1 collision attacks.

This tool uses Error Correction Level M which recovers approximately 15% of damaged codewords. Level L (7%) produces smaller QR codes but tolerates less damage. Level Q (25%) and H (30%) tolerate more damage (useful if you overlay a logo) but produce denser matrices. For 2FA QR codes displayed on clean screens, Level M balances density and resilience. If you plan to print the QR on paper that may get smudged, consider that the URI length determines the QR version (size), and higher EC levels push the version up, making modules smaller and harder to scan on low-resolution cameras.

This tool runs entirely client-side. No data is transmitted to any server. The secret is generated using the Web Crypto API's getRandomValues(), which is a cryptographically secure pseudorandom number generator (CSPRNG) seeded by the operating system's entropy pool. This is the same entropy source used by OpenSSL and system-level key generation tools. The risk vector is your browser environment: ensure no malicious extensions are installed, use HTTPS, and clear or do not persist the secret in localStorage if operating in a shared environment.

The TOTP period (T_X) defines the time window for each code. Most authenticator apps hardcode 30 seconds and ignore the period parameter in the URI. Google Authenticator, Authy, and Microsoft Authenticator all behave this way. If you set period=60 in the URI but your app uses 30, the codes will disagree 50% of the time. Only apps with full RFC 6238 support (FreeOTP, Aegis, KeePassXC) honor custom periods. Unless you control both the server validation and the authenticator app, use 30 seconds.

No. TOTP is a shared-secret system. If you lose the secret and have no backup, you must go through the service provider's account recovery process, which typically requires identity verification. Best practice: save the Base32 secret string in an encrypted password manager, print the QR code and store it in a secure physical location, or use an authenticator app that supports encrypted cloud backups (Authy, Aegis). This tool provides both the secret and a downloadable PNG for exactly this purpose.