What Is TOTP? How Authenticator Codes Work — and How to Use Our Generator

If you have ever opened Google Authenticator, Authy, 1Password, or Apple Passwords and typed a six-digit code that changes every 30 seconds, you have used TOTP — Time-based One-Time Password.

TOTP is the most common form of app-based two-factor authentication (2FA). It is stronger than SMS codes for most everyday threats, weaker than passkeys against real-time phishing, and still the default second factor on countless services.

This guide explains what TOTP actually is, how the codes are calculated, how to use the passwords.lu TOTP Generator & QR Tester, and the real situations where a client-side toolkit helps — without turning into a password manager or authenticator vault.

What Is TOTP?

TOTP stands for Time-based One-Time Password. It is an open standard (RFC 6238) built on HOTP (HMAC-based One-Time Password, RFC 4226).

In plain language: you and a website share a secret key. Both sides combine that secret with the current time to produce a short numeric code. If the codes match, the service knows you possess the secret — usually because it lives in your authenticator app or hardware token.

Unlike a static password, each TOTP code is valid only for a short window (typically 30 seconds). Unlike SMS 2FA, the code is generated on your device; it is not delivered over a phone network that can be intercepted or SIM-swapped.

How TOTP Codes Are Calculated

Under the hood, the flow looks like this:

1. 1

   Enrolment

   The service creates a random secret (often encoded as Base32) and shows it as a QR code containing an otpauth://totp URI.

2. 2

   Scan into your app

   You scan that QR into an authenticator app. The app stores the secret locally on your device.

3. 3

   Derive a time counter

   At login, the app reads the current Unix time, divides it by the period (usually 30 seconds), and gets a counter.

4. 4

   Compute the one-time code

   It runs HMAC (commonly SHA-1, increasingly SHA-256) over the secret and counter, then truncates the result into a 6- or 8-digit code.

5. 5

   Server verifies

   You type the code. The server repeats the same math with the same secret. If the codes match — sometimes also checking the previous or next time step for clock skew — you are in.

That is why clock sync matters. If your phone’s clock is minutes off, a perfectly typed code can still fail. It is also why two apps with the same secret always show the same digits at the same moment.

What Lives Inside a Setup QR Code?

A typical authenticator QR encodes an otpauth://totp URI. It usually includes:

• The shared secret (Base32)
• An issuer label (e.g. GitHub, AWS)
• An account name (email or username)
• Optional algorithm (SHA-1, SHA-256, SHA-512)
• Optional digits (6 or 8)
• Optional period (often 30 seconds)

Anyone who photographs that QR — or later extracts the secret — can generate the same codes. Treat the QR like a password: do not leave it on screen in a café, do not email it in the clear, and do not upload it to a random online “QR decoder.”

Important caveat: Google Authenticator’s multi-account “export / transfer” QR uses a different otpauth-migration:// format (protobuf bundle). Single otpauth://totp enrolment QRs are the normal case. Migration bundles need special handling and are not fully unpacked by every tool.

TOTP vs SMS vs Passkeys

Not all second factors are equal.

• SMS OTP: convenient, but vulnerable to SIM swap, SS7 interception, and number recycling. Avoid for high-value accounts when better options exist.
• TOTP (authenticator apps): offline-capable, not tied to your phone number, widely supported. Still phishable in real time — a malicious site can relay your live code.
• Passkeys / FIDO2 / hardware keys: designed to resist phishing because authentication is bound to the real site origin. Prefer these when available for email, banking, cloud consoles, and admin access.

Practical advice: use a password manager (or passkeys) for day-to-day logins; use TOTP where the service offers it and passkeys are not available; keep recovery codes offline; never rely on SMS alone for critical accounts.

What the passwords.lu TOTP Tool Is (and Is Not)

passwords.lu is a privacy-first client-side toolkit. The TOTP Generator & QR Tester lets you generate secrets, build authenticator QR codes, decode setup images, and verify codes — entirely in your browser.

Nothing is uploaded: secrets, QR screenshots, issuer names, and generated codes stay on your device. Cryptography uses Web Crypto.

It is not a password manager, not a replacement for Authy/Google Authenticator/1Password, and not a place to store long-term 2FA credentials. Most people should enrol 2FA directly in their authenticator or password manager. Use this tool for the jobs those apps handle poorly: paper backups before enrolment, desktop-only workflows, developer testing, clock-drift diagnosis, and offline QR inspection.

How to Use the TOTP Generator (Step by Step)

Open the tool at passwords.lu and choose one of three modes.

1. Generate — create a new TOTP secret and QR

Use Generate when you are creating a TOTP setup yourself (for example in a lab, a self-hosted app, or a temporary test account).

1. 1

   Enter an issuer (service name) and account label so the QR is readable later.

2. 2

   Choose secret length (more bytes = more entropy), algorithm, digits, and period. For new setups, SHA-256 is a modern default; SHA-1 remains the interoperability king for older apps and hardware tokens.

3. 3

   Click Generate new secret. The page shows a live QR, the Base32 secret, the otpauth:// URI, and the current 6-digit code with a countdown.

4. 4

   Optional: print a recovery setup sheet, copy the secret or URI, open the otpauth:// link in a local authenticator, or share once via PrivateNote if you need a secure one-time handoff.

5. 5

   Clear everything when you are done — especially on a shared computer.

If a production website is showing you its own enrolment QR, prefer Decode (below) over inventing a second secret. Your authenticator and the website must share the same secret.

2. Decode — inspect an existing authenticator QR

Use Decode when a service already displayed a setup QR and you want to understand or back it up before (or without) scanning with your phone.

1. 1

   Upload a PNG/JPEG/WebP screenshot, paste an image from the clipboard, or use the camera. Decoding runs locally.

2. 2

   Review the parsed issuer, account, algorithm, digits, period, and Base32 secret.

3. 3

   Print a recovery sheet or copy the secret into cold storage if that is your goal.

4. 4

   Optionally send the configuration into Test Authenticator to verify live codes on the desktop.

This is the safest path for “scan once and never see the secret again” services: decode first, store a recovery copy, then enrol your phone.

3. Test — verify codes and diagnose clock drift

Use Test when you already have a Base32 secret or otpauth:// URI and need to confirm codes — or figure out why a site keeps rejecting them.

1. 1

   Paste the secret or full otpauth:// URI.

2. 2

   Watch the current, previous (t−1), and next (t+1) codes.

3. 3

   Type the code shown on your phone. If it matches t−1 or t+1 instead of the current step, your clocks are skewed.

4. 4

   Adjust the verification window if you are testing tolerance for small drift.

Most “invalid code” tickets are clock problems, not wrong secrets. Seeing t−1 / t+1 match is a fast, local way to prove that.

Real Use Cases in Detail

Here is when a local TOTP toolkit earns its place — and how to run each job on passwords.lu.

When the setup QR appears only once

High-value accounts (AWS root, GitHub org owner, primary email, domain registrar) often show a 2FA QR only once. Many authenticator apps then hide the raw secret forever. Lose the phone, lose the seed, and recovery becomes painful — sometimes expensive.

Before you enrol your phone, open Decode on passwords.lu, load the QR, and print a recovery sheet or store the Base32 secret in truly offline cold storage (paper in a safe, encrypted USB kept offline). Then scan with your authenticator as usual.

You still need the service’s official recovery codes if offered. A printed TOTP seed is an extra safety net for the “QR was shown once” problem, not a substitute for account recovery policies.

Setting up 2FA when a phone isn’t available

Not every enrolment happens with a phone in hand. Laptops without a secondary device, secure rooms with phone bans, and jump hosts are common.

Screenshot the on-screen QR, drop it into Decode, extract the secret, and use Test to read live codes on the same desktop. You can later move the secret into a proper authenticator when policy allows — or keep a controlled desktop workflow for that environment.

Exercising custom TOTP parameters in staging

Building or testing a 2FA feature means exercising edge cases: 8-digit codes, SHA-256, 60-second periods, enrolment resets after every database wipe. Re-enrolling a physical phone for each cycle wastes time.

Use Generate to mint throwaway seeds, copy otpauth:// URIs into automated tests or staging docs, and use Test to validate t−1 / t+1 behaviour without touching a phone. Clear secrets when the session ends.

Diagnosing rejected codes that still look correct

Support threads are full of people who swear the digits are correct while the site rejects them. The usual culprit is clock drift between the phone and the server — even a few seconds can push you into the wrong time step.

Paste the account secret or URI into Test (from a backup sheet or Decode), then type the phone’s displayed code. If it matches previous or next, fix device time (automatic network time) or ask the service about server clock skew. If it never matches any step, you likely have the wrong secret, wrong algorithm, or wrong digit length.

Understanding a QR before you migrate authenticators

Moving from one authenticator to another is risky if you do not understand what a QR contains. Blindly scanning into a new vault without a backup plan is how people lock themselves out mid-migration.

Drop enrolment QR images into Decode and inspect issuer, algorithm, and secret offline before you commit. Single otpauth://totp QRs are fully supported on passwords.lu. Google Authenticator multi-account export bundles are detected but not unpacked yet — plan those migrations with the authenticator’s own transfer flow or official export tools.

Security Practices for TOTP Secrets

• Prefer passkeys or hardware keys for your most important accounts when the service supports them.
• Store authenticator backups with the same care as passwords: encrypted vault or offline paper — never chat, email, or cloud notes in plaintext.
• Do not photograph setup QRs in public spaces or leave them visible on shared screens.
• Use a client-side decoder (like passwords.lu) — never upload TOTP QRs to unknown websites.
• After copying a secret, clear the clipboard when you can.
• Remember: TOTP does not stop real-time phishing. If a fake login page asks for password + code, both can be relayed instantly.

FAQ

Key Takeaways

• TOTP is a shared-secret, time-based code standard used by authenticator apps.
• The setup QR contains the secret — treat it like a password.
• Passkeys beat TOTP against phishing; TOTP beats SMS for most account security upgrades.
• passwords.lu generates, decodes, and tests TOTP locally — it is not a vault.
• Best jobs for the tool: offline backup before enrolment, desktop-only setups, QA, clock-drift checks, and QR inspection during migrations.

Conclusion

Authenticator codes feel magical until you understand the boring truth: a secret plus the clock, hashed and shortened.

Once you see that, the hard parts become clear — protecting the secret, surviving device loss, and diagnosing time skew.

Use a proper authenticator or password manager for everyday 2FA. Reach for the passwords.lu TOTP Generator when you need a private, browser-local way to create, inspect, or verify those setups without sending anything to a server.

Related reading

• Passkeys: the next frontier in passwordless authentication
• Password generator vs password manager: what you actually need
• Share secrets safely with PrivateNote