Generate a Two-Factor QR Code — Free TOTP/HOTP Enrollment QR

Generate QR Codes: Worked Examples

Paste Your Secret Key, Configure the Name, and Scan

The following worked example walks through how to make qr codes for a personal Google account using this free browser-based generator:

1. Visit Google account settings. Go to myaccount.google.com → Security → 2-Step Verification → Get Started, choose Authenticator app, and tap Can't scan it? to reveal the plaintext base32 secret key.
2. Paste the credential into the generator. Copy the base32 value (e.g., JBSWY3DPEHPK3PXP) and paste it into the Secret Key field. Set the service name field to Google and the account field to your Gmail address. Leave the hash function, digit count, and interval at their defaults (SHA-1, 6, 30).
3. The QR code renders instantly. The tool encodes the URI otpauth://totp/Google:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Google and renders it as a scannable image. No data is sent anywhere — generation is entirely local.
4. Scan with Authy or any compatible app. Open Authy, tap the + button, and point your camera at the displayed code. Authy reads the provisioning URI, creates the account entry labelled Google, and immediately begins generating rotating codes.
5. Verify the first live code. Return to the Google setup page and enter the current six-digit code shown in Authy. If it matches, two factor authentication is fully active. Save your Google backup codes immediately.

Scan a QR Code Screenshot and Recover a Lost Account

Imagine this scenario: you switched to a replacement device, forgot to export your time-based credentials, and can no longer scan the original setup image from your old email. Here is the recovery flow using this two factor qr code generator:

1. Locate your saved backup codes. Most services generate 8–10 single-use recovery codes during initial enrollment. Retrieve those codes from wherever you stored them — a credential vault, a printed sheet, or an encrypted note.
2. Sign in using a backup code. On the sign-in form, choose Use a backup code or Try another way. Enter one of your stored recovery codes to regain account access.
3. Disable and re-enable two factor authentication. Once signed in, navigate to the settings page, temporarily disable two factor authentication, and immediately re-enable it to trigger a fresh configuration page with a new QR code.
4. Upload the new QR code screenshot. Take a screenshot of the new setup image, or use the upload function in this tool to decode qr code data and extract the fresh base32 credential automatically.
5. Re-enroll on your replacement device. Scan the regenerated QR code with your app on the new device, verify a live code, and save the new backup codes to prevent a repeat lockout. Consider storing credentials inside a protected backup in Authy or 1Password to enable app syncing across devices.

Using the Live Code to Complete Identity Verification

After scanning, your app displays a six-digit code alongside a countdown timer. Enter that code into the sign-in form before the 30-second timer hits zero. Most backends accept codes within a ±1 window (one interval before and after the current window) to account for minor clock drift, so a code generated just as the timer expires is usually still valid. If the site rejects it, wait for the next code rotation and try again before assuming the shared credential is wrong.

Troubleshooting, Security Practices, and Automating TOTP with the Online 2FA Generator

QR Code Will Not Scan or Secret Key Is Rejected

The most common causes of a QR scan failure are poor lighting, camera focus issues, and screen glare on a bright display. Try these fixes in order:

• Increase your screen brightness and move to a well-lit area to eliminate glare.
• Adjust camera distance — most phone cameras need 15–30 cm of clearance to resolve a QR code reliably. Point camera directly at the code without tilting.
• Download or screenshot the QR code and use the image upload scanner — an image upload scanner bypasses camera entirely and extracts the provisioning URI from the file.
• If the QR code still fails, choose the manual entry fallback: manually type secret characters directly into the app's Enter a setup key field. Remember that base32 characters are A–Z and 2–7 only; any 0, 1, 8, or 9 you see is almost certainly an ambiguous character being misread as O, I, B, or G respectively.
• If using a different rendering package (for example, swapping from qrcode.js to another package in a custom implementation), verify it correctly encodes the full provisioning URI including the service name parameter — missing parameters cause some apps to reject the code silently.

Clock Sync Issues Causing Invalid Code Errors

TOTP depends entirely on accurate time. If your device clock drifts even 60 seconds from the backend's clock, the time counter used by your app and the backend will diverge and produce an incorrect code every time. Fix clock drift by enabling automatic time sync:

• Android: Settings → System → Date & time → Set time automatically (enable)
• iOS: Settings → General → Date & Time → Set Automatically (toggle on)
• Windows: Settings → Time & language → Date & time → Set time automatically; sync now with time.windows.com
• Linux / Backend host: Ensure the NTP daemon (systemd-timesyncd or ntpd) is active and time synchronization is confirmed with timedatectl status

After enabling automatic time sync, wait for the next 30-second window and try the code again. If the problem persists, the issue may be a credential typo rather than time skew — re-enter the base32 value from scratch rather than copy-pasting from a cached source. Remember to set time automatically on the backend side too when troubleshooting time mismatches in a web application; the app and backend must agree on the current timestamp within the allowed window.

Account Locked Out — Recovery Steps

Losing access to your app — through a lost phone, factory reset, or broken device — is the most stressful scenario. Work through these recovery steps in order:

1. Try your backup codes. Most services accept a single-use backup code in place of a live time-based code. Retrieve your recovery codes from wherever you stored them (credential vault, printed sheet, encrypted local storage, or encrypted note).
2. Use an alternative second factor. Some services allow fallback to text message codes, a registered recovery email, or trusted contacts if your primary app is unavailable.
3. Contact official support with identity proof. For a locked-out situation with no backup codes and no alternative factors, contact the service's support team directly. Expect to complete a government ID check or confirm financial details for banking and crypto account retrieval. Crypto platform recovery flows are particularly strict — expect a multi-day review.
4. Never use third-party recovery services. Any website or individual claiming to recover your account for a fee is running a social engineering scam. Contact only official support channels.

Best Practices for Managing Your Two Factor Authentication Setup

Enabling two factor authentication is the starting point, not the finish line. The following practices keep your accounts protected against the evolving threats targeting multi-factor authentication in 2026:

• Always save your backup codes. Download and store the recovery codes every service generates at enrollment. Keep a copy in a credential vault and a second copy in an encrypted backup stored somewhere physically separate from your phone.
• Use multiple app devices. Export your time-based credentials using your app's export feature and import them onto a second device, or use Authy or 1Password, which support protected local storage and cross-device sync for those credentials so a lost phone does not lock you out.
• Beware of MFA fatigue attacks. If your phone starts receiving unexpected push approval requests — especially in the middle of the night — deny all of them and change your passphrase immediately. An MFA fatigue attack works by flooding you with approvals until you accidentally tap one.
• Guard against SIM swapping. Contact your carrier and request port-out protection and a carrier PIN on your SIM card. This single change prevents most SIM swap attacks where criminals social-engineer carriers into transferring your number to their own SIM card, giving them access to text message codes and account recovery flows tied to your phone number.
• Combine two factor authentication with a credential manager. Use unique passphrases per site, generated and stored by a password manager such as 1Password, Bitwarden, or LastPass, alongside TOTP. Some credential managers can store time-based secrets and autofill codes automatically, providing a seamless sign-in experience without sacrificing protection.
• Never share codes, even with support. No legitimate bank, service, or company will ever request that you read your verification code aloud, type it in a chat, or email it. Any request for a live code is a social engineering attempt — hang up and use the company's official contact channel.
• Audit your setup yearly. Conduct an annual review: list every account with two factor authentication enabled, confirm backup codes are current, enable it on newly created accounts, and revoke it from accounts you have closed. This hygiene practice catches stale recovery addresses and forgotten credentials before they cause problems.
• Upgrade to passkeys where available. FIDO2 / WebAuthn passkeys are phishing-resistant by design. A passkey is cryptographically bound to the specific domain it was created for, so a social engineering attempt against a fake sign-in page cannot harvest it. When Google, Apple, Microsoft, or GitHub offers passkeys, switch to them — they represent a genuine upgrade over TOTP.

Automating TOTP for CI/CD Pipelines and Test Automation

Code-based friction is one of the most common blockers in automated browser testing. Tools like Selenium and Playwright need to complete sign-in flows end-to-end, but a rotating six-digit code that expires every 30 seconds requires programmatic generation to avoid breaking the test suite. An endpoint-driven approach solves this without a physical device.

The REST endpoint accepts a QR code image via multipart/form-data using the qrcode field, or accepts a JSON request payload with the service name, shared credential, and hash function specified directly. The POST endpoint stores the time-based credential and returns a unique identifier along with the active code and an expiresAt timestamp:

curl -X POST \
  -F "qrcode=@/path/to/qr.png" \
  https://tools.beeceptor.com/2FA/TOTP/

Alternatively, upload via JSON to configure the hash function explicitly (SHA256 is recommended for stronger hashing in automated workflows):

POST https://tools.beeceptor.com/2FA/TOTP/
Content-Type: application/json

{
  "issuer": "your-ci-app.com",
  "secret": "2OLRLATN3OQZOCPA",
  "algorithm": "SHA256"
}

The response payload includes the unique identifier, active code, and expiry window. In subsequent test runs, use the GET endpoint with the unique identifier to retrieve the active code without re-uploading the credential — the stored credential persists for 90 days of active use, after which an inactivity purge removes unused records automatically. The complimentary tier allows 10 requests per minute per IP; the paid endpoint tier at $10 per month unlocks 25,000 calls per month, longer credential retention, and priority support for enterprise needs. This usage-based pricing model makes programmatic access practical for teams of any size without requiring a sign-up at the complimentary level.

In a Playwright test suite, retrieve the active code programmatically and inject it into the sign-in flow's validation step before the code lifespan expires:

// Node.js / Playwright example
const res = await fetch('https://tools.beeceptor.com/2FA/TOTP/' + SECRET_ID);
const { otp } = await res.json(); // e.g. "002881"
await page.fill('#totp-input', otp);
await page.click('#login-submit');

This pattern eliminates the need for a physical device during continuous integration runs, allows test suites to run fully headlessly in CI/CD workflows, and removes the manual step of generating codes. Because all HTTPS transfers use encryption and credentials are never exposed in response payloads beyond the active code, the protection model for automated validation remains sound. For development teams requiring a volume endpoint with rate limits above the complimentary tier, contact support about enterprise pricing. The permanent link for a registered credential also serves as a sharable bookmark so multiple team members can retrieve the active code without re-uploading credentials on every run.

Generating QR Codes Programmatically in ASP.NET Core

If you are adding two factor authentication to a custom web application rather than testing an existing one, ASP.NET Core Identity provides a built-in helper for the configuration page. The GenerateQrCodeUri method constructs the correctly formatted provisioning URI. Pass this URI to a rendering package such as qrcode.js to generate qr codes and display a scannable image in the browser:

window.addEventListener("load", () => {
  const uri = document.getElementById("qrCodeData").getAttribute('data-url');
  new QRCode(document.getElementById("qrCode"), {
    text: uri,
    width: 150,
    height: 150
  });
});

To change the service name displayed inside the app after initial enrollment, update the name parameter in the provisioning URI and regenerate the QR code — users will need to scan the updated image and re-enroll. You can also switch to a different rendering package without affecting the underlying time-based logic, since the package is only responsible for encoding the URI into a barcode, not for computing codes. Always check that the app and backend times remain synchronised after a package swap, because some backend implementations cache the time counter in a way that introduces drift on the backend side.

For teams who want to use offline version builds of this tool: download the offline version, disable network access, and confirm that the source code matches the published hash before trusting it in an air-gapped environment. The data never leaves the browser in either the online or offline app — processed locally in both cases, with no data stored on any external host and nothing transmitted beyond your own device.