Generate a Live TOTP Code — Free 6-Digit Code Generator
Paste an authenticator app's secret key into the TOTP Code Generator and watch your current 6-digit code update live, right beside a countdown ring that shows exactly how many seconds are left before it rotates. Match the algorithm, digits, and period to your real authenticator app's settings, and every code is computed entirely in your browser so the secret never leaves your screen.
Lost access to your phone and locked out of a critical account? A TOTP code generator running entirely in your browser gives you live, time-synced verification tokens without installing any mobile application — a genuine lifeline for engineers, QA testers, and anyone managing several configurations. Whether you need to test an authorization flow, debug a staging environment, or simply recover access, understanding how this open source, browser-based tool works puts you firmly in control of your two-factor setup.
What Is a Time-Based One-Time Password Generator and How Does It Work?
A time-based one-time password (TOTP) is a short-lived numeric code produced by combining a shared secret with the current timestamp. The mechanism is defined in the IETF standard known as RFC 6238, which itself extends HOTP (HMAC-Based One-Time Password, RFC 4226) by replacing a counter with a time value. Because both the client and server derive the same code from the same secret and the same 30-second timestep, no code is ever transmitted over the network during login — only verified against an independently generated value. This cybersecurity standard underpins modern multi-factor login across the industry.
How TOTP Protects Your Identity Beyond a Password
Static passwords are a single point of failure. Two-factor verification adds a second layer: even if your password leaks, an attacker still cannot log in without your current TOTP token. Because each code is a single-use code valid for only one timestep, code reuse is structurally impossible — a stolen token value is worthless within moments. This is why major platforms like GitHub, Google, and Microsoft make TOTP the backbone of their multi-factor setups, and why standards bodies prefer it over SMS, which is vulnerable to SIM-swapping. The underlying cryptography relies on HMAC — a keyed digest function — applied to the current Unix time divided by the period, producing short-lived token values that refresh automatically.
Compatibility With Your Existing Verification Setup
Because the open standard is vendor-neutral, TOTP tokens generated here are accepted by any service that supports a standard authenticator app. That includes Google Authenticator, Microsoft Authenticator, Authy, and any other consumer authenticators or enterprise MFA systems. The shared secret is always base32 encoded, so as long as you provide the same base32 secret your mobile application uses, the codes will match exactly. This web-based analog to a mobile app is particularly valuable in staging and integration testing scenarios where installing a totp app on a device is impractical.
Using the TOTP Code Generator Online: URL Parameters and URI Extraction
One of the most powerful features of this browser-based generator is the ability to pre-configure every setting via URL parameters, making it ideal as an engineer's tool for sharing links with teammates or automating test setups. Providing parameters in URL query strings means your entire configuration is encoded in a single bookmark or script — no manual re-entry required each time. Teams that need to generate TOTP codes across different systems will find this especially useful for managing totp tokens in browser environments without a mobile device.
Passing TOTP Parameters via URL Query String
The simplest usage passes only your raw private key directly in the URL:
https://totp.danhersam.com?key=YOUR_BASE32_SECRET
For advanced configuration, you can supply additional parameters to customise digit length, validity period, and digest algorithm in a single query string:
https://totp.danhersam.com/?digits=6&period=60&algorithm=SHA256&key=YOUR_BASE32_SECRET
You can also use the hash-based URL format if you prefer keeping the secret out of the query string portion:
https://totp.danhersam.com/#/YOUR_BASE32_SECRET
All computation happens inside browser memory — there is no data transmission to any server, no storage of secret keys, and no browser cache of your credentials. This no data transmission, no storage architecture is fundamental to the protection model of any trustworthy browser-based tool. Encryption of data in transit is also unnecessary because nothing leaves your device.
Below is the full URL parameter reference for this one time password browser tool:
| Name | Accepted Values | Default |
|---|---|---|
key | Base32-encoded secret string | Required |
digits | 6, 8 | 6 |
period | 30, 60 (interval in seconds) | 30 |
algorithm | SHA1, SHA256, SHA512 | SHA1 |
Extracting a Secret from an otpauth:// URI
When a service presents a scan image during its multi-factor setup screen, scanning that image with a mobile application imports an otpauth URI that encodes all configuration details. The otpauth URI format looks like this:
otpauth://totp/ServiceName:user@example.com?secret=BASE32SECRET&issuer=ServiceName&algorithm=SHA1&digits=6&period=30
To use your secret in this tool: locate the secret= parameter inside the URI, copy the base32 encoded value that follows it, and paste it into the key field (or append it to the URL as shown above). The import via scan image workflow achieves the same result if your browser can access the image — the tool decodes the otpauth uri and extracts the secret parameter automatically. QR code import is convenient when onboarding to a new service and you want to verify codes in both your totp app and this online generator simultaneously.
Choosing the Right Settings to Generate TOTP Codes Securely
Most users never need to change the defaults, but understanding each option helps you make an informed decision — especially when your service's documentation specifies non-standard digit configuration or algorithm requirements.
Digit Length: 6 Digits vs. 8 Digits
The vast majority of services use 6 digits, which provides one million possible token values per timestep. Upgrading to 8 digits raises that to 100 million, meaningfully reducing brute-force risk in high-assurance or financial contexts. However, 8-digit codes are less convenient to type and are not supported by all standard authenticator apps. For everyday login protection and broad compatibility with major platforms, 6 digits is the sensible default. Reserve 8 digits for internal systems where you control both the server and the authenticator, or where your audit explicitly calls for greater entropy.
Algorithm Comparison: SHA-1, SHA-256, and SHA-512
The totp algorithm uses a SHA hash as its underlying digest method. Here is how the three options compare:
| Algorithm | Security Level | Compatibility | Common Use |
|---|---|---|---|
| SHA-1 | Standard (sufficient for OTP) | Universal — all standard authenticator apps, Google Authenticator, Microsoft Authenticator | Default for virtually all services; industry-standard algorithm for TOTP |
| SHA-256 | Strong — stronger digests, higher randomness | Limited — some enterprise and open source totp libraries only | Internal tools, custom verification flow, advanced scenarios |
| SHA-512 | Highest — stricter digest, maximum randomness | Minimal — specialist systems; configuration mismatch risk is high | High-assurance internal systems with controlled authenticator deployment |
An important note on cryptography: while SHA-1 has theoretical weaknesses in other contexts, for TOTP the short-lived, single-use nature of each code means SHA-1 remains perfectly adequate. The real risk of choosing SHA-256 or SHA-512 is a configuration mismatch — if your server expects SHA-1 and you generate with SHA-512, every code will be wrong. Always match the algorithm your service specifies.
Validity Period: 30 Seconds vs. 60 Seconds
The standard 30-second timestep defined in the open standard balances protection and usability — codes refresh quickly enough to limit exposure, yet give you enough time to copy and paste without rushing. A 60-second period doubles your window, which is helpful in high-latency environments or accessibility contexts where users need more time. Most services enforce the shorter interval; a 60-second period is best used only when you control both ends of the verification flow. Servers typically implement a one-step grace window (one-step grace window) accepting one previous and one future code to tolerate minor clock skew between client clock and server clock, so a short verification window is rarely a practical problem.
Troubleshooting Your TOTP Code Generator: Common Issues and Fixes
Even a correctly configured totp code generator can produce codes that a server rejects. Below are the most frequent causes and their solutions.
Why is my generated TOTP code not being accepted?
- Clock synchronization: TOTP depends on accurate time. If your device clock is even 60 seconds off, codes will fall outside the server's tolerance window. Sync your system clock via NTP and ensure clock synchronization is enabled.
- Wrong secret: Double-check the base32 secret you entered. A single character error in the secret format produces completely different token values.
- Configuration mismatch: Confirm the digest algorithm matches what the server expects — the default is SHA-1 for almost all services.
- Digit length mismatch: Ensure digit length matches the service setting. Mixing 6 digits and 8 digits is a common source of intermittent failures.
- Token expiry during entry: If your code expires mid-submission, wait for the next refresh and enter the new code immediately.
Is it safe to use a browser-based TOTP tool?
Yes — provided the tool is a browser-based generator that performs all computation locally. Your secret keys never leave your browser; there is no data transmission to any external server and no storage in any database. The open source nature of tools like totp-generator means the code is publicly auditable, adding an extra layer of transparency for those concerned about privacy and data integrity. Never enter your secrets into a tool whose source code you cannot verify or that makes network requests with your key.
How do I manage secrets across multiple environments?
When reusing a secret across several configurations (staging environment, production environment, QA testing), bookmark the full URL including all url parameters for each setup separately. You can save applications as distinct bookmarks — there is no fixed limit to how many you manage this way, though some teams track up to 10 apps or more. This approach gives you clean application management without storing application secrets in a shared document. For team-wide access, share the pre-configured URL rather than the raw secret, and rely on your organisation's access control policies to govern who holds the link. Using time-based one time passwords this way means codes are always updating in real time across every environment.
How does TOTP compare to WebAuthn, passkeys, or SAML?
TOTP is part of the multi-factor verification family alongside WebAuthn, passkey, SAML, and JWT-based flows. The hardware-key standard and passkeys offer phishing-resistant, passwordless login that does not rely on shared secrets, making them stronger for consumer account protection in the long term. Federation standards like JWT are session and federation mechanisms rather than direct verification methods. TOTP occupies a practical middle ground: it is widely supported, requires no special hardware, and integrates easily into any verification flow — making it the dominant standard for layered login today. MFA systems often layer TOTP alongside the hardware-key standard or other factors for defense in depth.
What is the role of this tool in debugging and QA testing?
For engineers, this online one-time password generator is primarily a debugging and QA testing instrument for verification flows without a physical mobile device. During integration testing you can generate codes, copy code directly from the browser via clipboard copy, paste code into your test harness, and automate URL-driven secret injection. Teams running qa testing across a staging environment benefit from being able to generate TOTP codes on any machine — no mobile dependency, no synchronisation lag with a physical totp app. The automatic refresh of live codes ensures your test scripts always receive a current, valid token output rather than an expired one.
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.