TOTP Code Generator

Paste your base32 secret key into a TOTP code generator and you get the same 6-digit authenticator code your phone would show right now, refreshed every 30 seconds because the code is built from the current time. It is handy when you need a quick verification code for a login, when you are checking a new two-factor setup, or when your usual device is out of reach.

How a TOTP Code Generator Turns a Secret Key into 6 Digits

A time-based one-time password (TOTP) is a short, temporary, single-use number that proves you hold a shared secret without ever sending that secret to the website. The site and your device each know the same key. Each side counts how many 30-second windows have passed since January 1, 1970 (UTC), runs that counter through HMAC, and cuts the result down to a few digits. If both sides agree on the secret and the clock, both arrive at the same number.

The method is written down in RFC 6238, published by the IETF, which builds on the counter-based HOTP method from RFC 4226. Because it is an open standard, any authenticator app and any online one-time password generator produce identical output for identical settings.

The formula behind every TOTP code

Two short steps define the whole thing. First, the time step counter, then the truncated hash:

Here \(T\) is the current Unix time in seconds, \(T_0\) is 0, and \(X\) is the period, 30 seconds by default. The password itself is:

where \(K\) is your decoded secret and \(d\) is the number of digits. Using 6 digits means taking the remainder after dividing by 1,000,000; using 8 digits divides by 100,000,000, so a code can begin with a zero and must keep it.

Inputs a TOTP authenticator needs

Every TOTP authenticator, whether it lives in your phone or in a web page, needs the same handful of settings. The defaults below are what nearly every service uses.

Worked Example: One Authenticator Code, Step by Step

Take the base32 secret KRSXG5CTMVRXEZLUGEZDGNBV and the moment 03:22:47 UTC on June 12, 2026, which is Unix time 1,781,234,567. The calculation runs like this:

1. Divide 1,781,234,567 by 30 and drop the remainder: the counter is 59,374,485. The current step began at 03:22:30, so 17 seconds have passed and 13 remain.
2. Decode the base32 secret into bytes and compute HMAC-SHA1 of the counter. The 20-byte hash ends in a6, so the low nibble, 6, is the offset.
3. Read four bytes starting at offset 6 and clear the top bit. That gives the integer 301,633,493.
4. Take the remainder after dividing by 1,000,000. The 6-digit code is 633493.

Change only the algorithm or digit count and the same instant yields a different number, which is why a mismatch in any setting makes a code fail.

When the code refreshes

The code stays put until the counter ticks over at 03:23:00, 13 seconds later. Then it changes to 471078, and 30 seconds after that to 388380. The step before ours, which ended at 03:22:30, was 788856. A countdown bar in a generator simply shows the seconds left in the current window.

Choosing SHA-1, SHA-256 or SHA-512 in a TOTP Authenticator

The algorithm decides which hashing function sits inside HMAC. SHA-1 is what Google Authenticator, Microsoft Authenticator, Authy and 1Password expect by default, and for HMAC use it remains acceptable. Pick SHA-256 or SHA-512 only when you control both the client and the server and the service explicitly asks for it; many consumer apps silently ignore anything but SHA-1 and will show a code that never matches.

Digit length works the same way. Six digits is the common choice because it is easy to type. Eight digits adds entropy: a guess has a 1 in 100,000,000 chance rather than 1 in 1,000,000, but few consumer apps support it.

Setting Up a 2FA Generator with a Base32 Setup Key or otpauth URI

When a site enables two-factor authentication, it shows a QR code and, below it, a text setup key. That text is the same secret in base32 form, so you can enter it directly instead of scanning.

Entering the secret key

Copy the key to your clipboard, remove spaces if there are any, and paste it into the generator. Base32 uses only the letters A to Z and the digits 2 to 7; a 0, 1, 8 or 9 means the string is not valid base32.

Using an otpauth URI or QR image

A QR code is just an encoded link such as otpauth://totp/Example:you?secret=KEY&issuer=Example. To extract the secret, take the value after secret=. Some tools let you drag a QR image onto the page or paste it, and read the otpauth link for you (every otpauth:// link follows the same pattern), which is the quickest way to import an existing entry. Optional query parameters in that URL can carry the algorithm (spelled SHA256 here, without the hyphen), digits and period.

• Secret: the base32 string, kept private like a private key.
• Issuer and label: names only, they never change the result.
• Algorithm, digits and period: change them only if the service states different values.
• Tools that handle multiple entries let you keep several secrets side by side for quick switching.

Tracking Down a Rejected Staging Login with a One-Time Password Generator

Priya Nair is a QA engineer whose staging login keeps answering "invalid code" for a test account. The setup screen gave her the base32 secret MFRGGZDFMZTWQ2LKNNWG23TP, the defaults are SHA-1, 6 digits and a 30-second period, so she pastes the secret into the generator and reads this time-based one-time password, a TOTP code, as 679191 from her laptop.

The staging server's log says the request arrived at 09:14:52 UTC and was checked against counter 59,657,429, whose expected value is 710291. Her code is not that, and not the previous or next window either: the server's one-step tolerance, the RFC 6238 recommendation, accepts 353643, 710291 and 419059. Counter 59,657,431 is two steps ahead, which is exactly what 679191 corresponds to.

Two steps ahead means her laptop clock reads somewhere between 60 and 90 seconds past the server's. She opens the system clock settings and finds it 47 seconds fast, enough to push 09:14:52 to 09:15:39 and into the 09:15:30 window. She turns on automatic time sync, regenerates, and the page now shows 710291. The login succeeds on the next attempt.

The next step is a one-line change to her test plan: before generating any code, compare the laptop clock with the server's log timestamp, and if the gap is over 30 seconds, fix the clock first instead of regenerating codes.

Is It Safe to Use an Online One-Time Password Generator in Your Browser?

It depends on where the calculation runs. A well-built page does everything in your browser with JavaScript, so nothing is sent to a backend and no secret is stored or uploaded; this one works that way. Your browser tab holds the secret only while the page is open, and closing it clears it.

Even so, treat a long-term secret carefully. For an important account, keep the key in a trusted password manager or authenticator app rather than leaving it in a tab, and do not store it in notes or chat. A generator is best for a quick check, a recovery, or a one-off login. If you want to skip codes entirely, a passkey resists phishing in a way a typed code cannot, since a convincing fake site can still collect a six-digit number.

Why Your TOTP Code Is Rejected: Clock Skew and Troubleshooting

When a login says the code is wrong, the cause is almost always one of a few things. Work through them in this order for faster troubleshooting.

Clock skew and the grace window

TOTP depends entirely on time. If your device clock is off by even a minute, you compute a different counter. Servers usually allow a grace window of one step either side, so a code from the previous or next window can still pass, but larger clock skew fails. Switch on automatic time sync and try again. The code also has to be entered before it can expire; if fewer than three seconds remain, wait for the refresh.

Algorithm or digit mismatch

A mismatch in algorithm, digit count or timestep length gives a valid-looking but wrong code. Compare each setting with what the service displayed during setup.

A wrongly typed secret

Letters that look alike are the usual culprit. Re-copy the secret rather than retyping it, and confirm the string really is a base32 value.

Using a 2FA Generator for Testing and QA

A developer or QA engineer leans on a 2FA TOTP code generator for testing and debugging a login flow without a phone. You create a test account, copy the secret from its setup screen, and generate the verification code the server expects. A few habits keep this reliable, and the same security care applies to test secrets:

• Use a separate secret per environment, because sharing one between staging and production causes confusing failures.
• Verify with an API call and a tolerance of one step for clock drift.
• Log the counter, not the code, when you investigate a failed login.

The same secret, algorithm and period should give an identical value in your test harness, in this tool and in any app, which makes it a trustworthy reference.

Authenticator App vs Online Generator: Google, Microsoft, Authy and 1Password

All these authenticator apps run the same algorithm, so none is inherently more correct. The real differences are convenience and where the secret lives. A phone app keeps tokens on a device you carry and can lock with a biometric; a password manager syncs them across devices; an online generator needs nothing installed but only holds a secret while the tab is open. Each value is a one time password that is only good for its window, and because the shared secret is the same everywhere, the codes on your screen and on your phone should always agree, assuming the same settings.

If the two disagree, check the standard parameters first, then your device time. If you ever lose your phone, the setup key you saved at enrolment is what lets you rebuild the entry, so file it somewhere safe and encrypted. Never share that key with anyone claiming to need it for support.

Frequently Asked Questions

How does this tool compute the code?

It follows RFC 6238 (TOTP) exactly: your Base32 secret is decoded to bytes, combined with the current time divided into 30-second (or custom) intervals via HMAC (SHA1, SHA256, or SHA512, computed with the browser's native Web Crypto API), then truncated down to a 6- or 8-digit code the same way every authenticator app does. The algorithm was verified against the official RFC 6238 test vectors during development.

Why does the code sometimes look wrong or not match my app?

The most common cause is a clock mismatch -- TOTP codes are time-based, so if your device's clock has drifted, the computed code won't match. Also double-check the algorithm, digits, and period match what the service actually issued you; most use the defaults (SHA1, 6 digits, 30 seconds), but a few don't.

Is it safe to paste my 2FA secret into this tool?

The secret is used entirely in your browser to compute the code locally -- it is never transmitted, logged, or stored anywhere, and disappears the moment you reload the page. That said, treat any TOTP secret as sensitive: anyone with it can generate valid codes for your account, so only use this on a device you trust.

What is this tool useful for?

Verifying an authenticator-app setup without needing your phone in hand, debugging a TOTP integration you're building, or checking that a secret and its resulting codes are actually correct before rolling it out.

Why does the code change right as the ring empties?

That's expected -- the ring shows how much of the current 30-second (or custom-period) window is left. When it fully drains, the time counter increments and a brand new code is computed, exactly matching how your physical authenticator app behaves.