Adding two-step login to an app starts with one random value, and a TOTP secret generator creates it for you in a single click. The shared secret it produces is the only thing your server and your users' phones have in common, so it has to be long, random and kept private.
How a TOTP Secret Generator Creates Your Shared Secret
A TOTP secret key generator pulls bytes from a cryptographically secure random source, then encodes them as text you can paste into a setup screen. Nothing about the result depends on the time. Time only enters later, when an app mixes the stored value with the clock to produce a code. That is why the tool creates the shared secret and not a live code. The two factor qr code generator gives you a copy-ready result instantly, with no account required.
Because the value never has to leave your device, a good generator runs client-side. Everything happens in your browser: the bytes are created there, encoded there, and never stored or sent anywhere.
Why Base32 Encoding Is Used
Base32 uses only the letters A-Z and the digits 2-7, as defined in RFC 4648. There are no lowercase letters and no look-alike characters such as 0 and O, so a person can read a base32 secret aloud or type it by hand without mistakes. Every authenticator app accepts this alphabet.
Entropy and Secret Size
Entropy measures how unpredictable the value is, in bits. Twenty random bytes give 160 bits, the length the one-time password standards recommend. Shorter keys still work in most apps, but they leave less room against guessing, so use 20 bytes unless a legacy system forces something smaller.
Using the Online TOTP Code Generator Step by Step
The tool gives you a key and the settings to go with it. Here is the full flow:
- Pick a secret size. The default of 20 bytes suits almost every integration.
- Click the generate button to create the key. Use bulk generation when you need one for each test account.
- Enter an issuer and an account name so the otpauth URI is labelled properly.
- Copy the secret to the clipboard, or turn the link into QR codes and scan one with your authenticator.
- Store the secret on your server, encrypted, and attach it to that user.
The same page also works as a TOTP code generator for checking your work: paste the key into a second tool or a test script and confirm the codes match.
Building the otpauth URI and QR Code
An otpauth URI packs the secret and its settings into one link, such as otpauth://totp/Acme:[email protected]?secret=...&issuer=Acme. Turn that link into a QR code and a user can enroll by pointing a phone at the screen instead of typing 32 characters. If you only have a saved QR image, the secret= value inside the link is the key itself.
- secret: the Base32 value, required.
- issuer: your app name, shown above the code in the user's list.
- algorithm, digits, period: optional, and they fall back to SHA-1, 6 and 30.
TOTP Authenticator Settings: Algorithm, Digits and Period
Every TOTP authenticator expects the same three settings on both sides. If the server and the app disagree on any of them, every code fails, even though the secret is right.
SHA-1, SHA-256 and SHA-512
The algorithm is the hash function inside the calculation. SHA-1 is the default and works in Google Authenticator, Microsoft Authenticator, Authy and 1Password. SHA-256 and SHA-512 are stronger, but some apps ignore the setting and silently fall back to SHA-1, so test with the app your users actually have.
6 Digits or 8 Digits
Six digits is the common choice and the easiest to type before the clock runs out. Eight digits make a random guess 100 times harder, but fewer consumer apps support that digit length. Keep the default 30 seconds unless you control both ends.
Worked Example: A 20-Byte Authenticator Secret
Take 20 random bytes. The generator returns the authenticator secret JWISVR2Y4MFXN5AZUKGTLPTA24OJGT7K. Each Base32 character carries 5 bits, so the length follows from the byte count:
$$\text{characters} = \left\lceil \frac{\text{bytes} \times 8}{5} \right\rceil = \left\lceil \frac{20 \times 8}{5} \right\rceil = 32$$
The number of possible values grows as \(2^{\text{bits}}\), which for 160 bits is about \(1.46 \times 10^{48}\). The table shows how the common sizes compare.
| Secret size | Entropy | Base32 characters | Possible values |
|---|---|---|---|
| 10 bytes | 80 bits | 16 | 1.21 × 1024 |
| 16 bytes | 128 bits | 26 | 3.40 × 1038 |
| 20 bytes | 160 bits | 32 | 1.46 × 1048 |
| 32 bytes | 256 bits | 52 | 1.16 × 1077 |
Now feed that secret to an app at Unix time 1,790,000,010. Dividing by 30 gives time step 59,666,667, and the app returns 317817 with 6 digits or 36317817 with 8 digits. Move the clock to the next 30-second window and both numbers change completely.
How Authenticator Apps Turn a Secret Key Into Codes
The RFC 6238 method behind a time-based one-time password has three moves. First, take the current Unix timestamp and divide it by the period to get a counter. Second, run the counter and the secret through HMAC. Third, the result is truncated to the last 6 or 8 digits. Both sides do the same arithmetic, so no network call is needed to agree on a one-time password.
Each token is single-use in practice and it will expire when the window closes, which is what makes it a useful second factor for two-factor authentication.
Clock Skew and the Verification Window
Phones drift. Servers therefore accept the previous and next code as well as the current one, a verification window of plus or minus one step. The cost is small: with 6 digits, three valid codes mean a random guess succeeds 3 times in a million. If codes keep failing, check clock skew before you suspect the secret.
Implementation Examples and Terminal Commands
Once you have a key, your back end only needs a library to verify codes. In Python, pyotp exposes verify. In Node.js, otplib does the same job, and PHP has several maintained packages. Wrap any of them behind a small API route and rate-limit it.
You can also skip the page entirely. From a terminal, openssl rand 20 | base32 prints a valid key, and a short Python snippet using secrets.token_bytes(20) does the same. These implementation examples are handy when seeding a database during testing.
Seeding a TOTP Secret Key Generator Into a Staging Login
Marta Okafor maintains a booking app and has to switch on two-factor authentication for 14 staging accounts before a Thursday audit. She wants a different secret per account, so she opens the generator, sets the size to 20 bytes and runs the bulk option for 14 keys.
The first one comes back as MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43U, 32 characters, 160 bits. She types staging.bookly.example as the issuer and [email protected] as the account, copies the otpauth link, and pastes the secret into her own test harness before touching the database.
Her harness reports code 804159 for the current 30-second step, and the staging server accepts it on the first try. Then she shifts the harness clock forward 45 seconds on purpose. The server still rejects the stale code, which confirms its verification window is plus or minus one step rather than something looser. NIST SP 800-63B treats a code like this as a single-use authenticator, so a rejection at that distance is the correct result.
Her next action is concrete: she loads the other 13 keys, encrypts them in the staging vault and reruns the same clock-shift test with qa-08. The 14 secrets are generated in under a minute, and the audit checklist item for per-user secrets is ticked.
Keeping a Private Key Safe: 2FA Security Rules
The code is public, but the private key is not. Anyone holding it can mint valid codes forever, so treat it like a password.
- Show the secret once, at enrollment, and never log it.
- Keep it stored encrypted at rest, and never display it again after setup.
- Use a fresh value for every user and environment. A secret reused across staging and production blurs your tests and widens the damage of a leak.
- A secret is practically impossible to crack from the codes it produces, but a convincing fake login page can still steal a live code. Codes do not stop phishing, which is why passkeys and passwordless sign-in exist.
Good security here comes from random generation, safe encoding and careful storage, not from secrecy of the method. Give users a recovery path if they lose a phone, keep your server clock accurate, and consider a passkey or other passwordless option for sign-in that resists phishing outright.
For developer work such as testing, debugging and QA, a throwaway secret that lives only in a browser tab is the secure choice. When you wire it into your authentication flow, confirm the hashing settings and every other integration detail match on both sides, and keep the timestep identical too.
Frequently Asked Questions
- What is a TOTP secret?
- A TOTP secret (also called a seed or shared key) is the random value an authenticator app and a service both store to generate matching time-based one-time codes. It's usually shown as a Base32 string (letters A-Z and digits 2-7) because that alphabet is easy to type and scan from a QR code without ambiguous characters.
- How long should my TOTP secret be?
- RFC 4226 (the HOTP specification TOTP builds on) recommends at least 128 bits, and specifically suggests 160 bits for HMAC-SHA1-based implementations. This tool defaults to 160-bit (32 Base32 characters), which matches what most services and authenticator apps generate. 80-bit (16 characters) is shorter and easier to type manually, but offers a smaller margin of safety.
- Is this secret compatible with Google Authenticator, Authy, and other apps?
- Yes. The Base32 output is the standard format every major authenticator app (Google Authenticator, Authy, Microsoft Authenticator, 1Password, Bitwarden) expects, either typed in manually or embedded in an otpauth:// QR code. Use the OTPAuth URI Builder or Two-Factor QR Code Generator to turn this secret into a scannable enrollment code.
- Does the secret get sent anywhere?
- No. This tool generates the secret entirely in your browser using the Web Crypto API's cryptographically secure random number generator. Nothing is transmitted, logged, or stored — reload the page and the secret is gone.
- Can I use this secret for both TOTP and HOTP?
- Yes — the secret itself is just random key material; whether it's used with a time counter (TOTP) or an event counter (HOTP) is decided when you build the otpauth:// URI or configure the service, not by anything encoded in the secret.