Generate TOTP secret keys with QR codes for authenticator apps. Configure period, digits, and algorithm (SHA-1/SHA-256/SHA-512).
Generates a fresh random TOTP secret plus the QR code an authenticator app scans to enroll it. Configure the period (30 seconds by default), the digits (6 by default), and the HMAC algorithm - SHA-1, SHA-256, or SHA-512. The secret, the QR, and the underlying otpauth:// URI are produced locally in your browser; nothing is uploaded. The usual surprise: click generate and you get a brand-new key - the one on screen is gone once you generate again, so save the Base32 string immediately, and make sure the algorithm, digits, and period you picked match what the service verifying your codes expects, or every code will be rejected.
Generating a key means producing random bytes in the browser and encoding them in Base32, the alphabet authenticator apps expect: A-Z plus 2-7. The usual default size is 160 bits, which encodes to exactly 32 characters with no padding - the same size as the shared secret in RFC 6238's test vectors. You can copy the string or scan the QR; both carry the same secret.
The QR encodes a line of text, not an image of the key: an otpauth:// URI, the format defined for Google Authenticator and read by virtually every authenticator app - otpauth://totp/Issuer:Account?secret=BASE32&algorithm=...&digits=...&period=... Scanning imports the label, the secret, and those settings. The app then derives codes from the secret and the current time, so any mismatch between the URI's settings and the verifying service's configuration makes every code wrong.
No. The codes rotate every 30 seconds, but the secret itself never expires and is not time-limited: it stays valid until the enrollment is deleted from both the app and the service. That permanence is why the Base32 string deserves password-level protection - and why rotating a factor means generating a new secret, never waiting for the old one to lapse.
Not in any way that matters here. The security of TOTP rests on keeping the secret secret, not on the hash, and RFC 6238 defines SHA-1, SHA-256, and SHA-512 as valid alternatives. What decides your choice is the verifying service: it must accept the mode you enroll with. Most services still issue SHA-1 with 6 digits, so exotic settings usually just produce codes the server rejects.
The 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.