Generate QR codes for TOTP authenticator app setup with configurable issuer, account, and algorithm parameters.
This tool turns an issuer, an account name, and a Base32 secret key into a scannable QR code that authenticator apps like Google Authenticator or Authy can scan to enroll a new TOTP token. It assembles the otpauth://totp/ URI and renders it as a QR; the algorithm, digit count, and time step you choose are baked into that URI, and the app must agree with them exactly or every code it shows is rejected. The catch most people hit first: the secret must be a Base32 key, not a plain password. The tool does not verify the secret, so a bad one produces a scannable QR that never works.
A concrete input and expected output from the current implementation.
Input
Issuer: Example, Account: [email protected], Secret: JBSWY3DPEHPK3PXP, Algorithm: SHA256, Digits: 6, Period: 30
Expected output
otpauth://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Example&algorithm=SHA256&digits=6&period=30, rendered as a scannable QR image
The label 'Example:[email protected]' names the account, the explicit algorithm=SHA256 makes the app use SHA-256 instead of the SHA1 default, and the Base32 secret is the key the app stores and feeds into the TOTP computation to produce 6-digit codes every 30 seconds.
The tool composes the key-format URI otpauth://totp/{issuer}:{account}?secret={key}&issuer={issuer}&algorithm={alg}&digits={n}&period={s} and encodes that string as a QR image. When an authenticator app scans the image it parses the URI, stores the Base32 secret together with the parameters, and displays the label 'issuer:account'. Everything the app needs must travel inside that one string, so the QR necessarily contains the secret itself.
The URI states the hash algorithm (SHA1, SHA256, or SHA512), the digit count (usually 6, sometimes 8), and the time step (30 or 60 seconds); the scanning app uses exactly those values, so they must match what the service enforces. SHA1 with 6 digits and a 30-second step is the near-universal default; choose SHA256 or SHA512 only when the service explicitly requires them.
The usual causes, in order: the secret was not valid Base32 (a password typed into the secret field), the algorithm, digit count, or period in the URI differs from what the service enforces, or the key itself is not the one the service issued. Regenerate with the exact key and parameters the service documented, scan again, and retry; the tool cannot tell you which case it was.
No. Everything happens in the browser: the URI is assembled and rendered into a QR locally, and nothing is uploaded. That makes the tool reasonable for re-encoding a real secret, with one caveat - the QR itself is a machine-readable copy of that secret, so generate it on a screen you control and treat the image as sensitive.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.