otpauth:// QR Code Builder

Every authenticator app imports a new account the same way: scan a QR code that encodes an otpauth:// URI containing the secret and a handful of configuration parameters. Generating that QR by hand means constructing the URI correctly and then finding a QR tool that will render it without uploading anything. otpauth:// QR Code Builder does both steps in one form — fill in the account details, and the QR and the raw URI update live as you type.

The tool covers both TOTP (time-based) and HOTP (counter-based) one-time passwords, with full control over algorithm, digit count and period. All rendering runs in your browser. The secret never leaves the tab.

Getting a Scannable QR in Four Steps

1. The form opens with a working example already filled in: alice@example.com as the account, MyApp as the issuer, and JBSWY3DPEHPK3PXP as the secret — a well-known Base32 test vector that every RFC 6238 implementation uses. The QR code renders immediately and can be scanned to verify the tool works before you enter your own values.
2. Replace the secret with your real Base32 seed. Spaces and = padding are stripped automatically. If the field contains a non-Base32 character, the tool shows “Secret must be a Base32 string (A–Z and 2–7 only, with optional spaces or = padding)." and disables the output until the value is corrected.
3. Set the account name and issuer. Both appear in the authenticator app next to the code. Leave the algorithm, digits and period on their defaults (SHA-1 / 6 / 30) unless your server documentation specifies otherwise.
4. Click Download PNG to save the QR, or copy the raw URI from the Generated URI panel to embed it in a setup page or test it in a script.

What Each Field Controls

• Type (TOTP / HOTP): TOTP generates codes from the current time and is what virtually every site uses. HOTP generates codes from a counter that increments on each use; select it only when your server specifically implements the HOTP variant.
• Issuer: the service or application name shown in the authenticator app. When set, the URI label takes the form Issuer:Account, which prevents name collisions when the same email address is used across multiple services.
• Algorithm: SHA-1 is the correct choice for almost every system. SHA-256 and SHA-512 are included for completeness but most authenticator apps warn or fail silently on non-SHA-1 TOTP.
• Digits (6 / 7 / 8): the length of the one-time code. 6 is the universal standard; 8-digit codes are used by a small number of financial services.
• Period: how often the TOTP code changes, in seconds. 30 seconds is the RFC 6238 default and the only value most apps support. 60 and 90 seconds are available for systems that need a longer window.

Edge Cases Worth Knowing

• URI length cap. The QR encoder supports versions 1–7 at error-correction level M, which allows up to roughly 120 bytes of UTF-8 data. A very long issuer, account or secret may exceed this and show the error “URI is too long to encode as a QR code." Shorten the issuer or account name, or use a shorter Base32 secret (160 bits / 32 Base32 characters is more than enough for TOTP security).
• Non-default settings and app compatibility. Changing the algorithm to SHA-256 or SHA-512, or the digits to 7 or 8, produces a valid URI that some authenticator apps will reject or ignore silently, falling back to SHA-1 / 6 digits regardless. Test with your specific app before deploying.
• The secret is case-insensitive. Base32 is case-insensitive and the tool normalises the input to uppercase before building the URI. jbswy3dpehpk3pxp and JBSWY3DPEHPK3PXP produce identical output.