Generate a TOTP Secret — Free Random Base32 Key Generator

Every time you add two-factor authentication to an application, the first decision you make — and the most security-critical one — is how to produce a strong, unpredictable TOTP secret generator output that your server and your users' authenticator apps can share. Get that shared seed wrong and the entire chain of login security falls apart. This page gives you a free, browser-based, client-side totp secret generator that keeps all values on your device, plus everything you need to wire the result into real code, QR codes, and enterprise provisioning workflows.

How the TOTP Secret Generator Creates a Cryptographically Strong Seed

How a TOTP Secret Works Under the Hood

A time-based password (TOTP) is defined in RFC 6238 and builds on the HMAC-based specification for a one time password. At runtime, both the server and the verification app independently compute an HMAC-SHA1 digest over the concatenation of the shared credential and the current Unix timestamp divided by the configured period (typically 30 seconds). The last four bytes of that digest are truncated into a 6-digit code that refreshes every time the floor of unix_timestamp / period changes — updating in seconds and never repeating. No network communication occurs after the initial provisioning step; the magic is that both sides hold the same seed and the same clock.

The formula that drives every TOTP time-based password is:

where t is the current Unix timestamp, t₀ is the Unix epoch (0), and X is the time step in seconds (default 30). The one-time password is then:

where K is the secret key and d is the number of digits (default 6).

Seed and Private Key Explained

The generator outputs a base32-encoded string — specifically, a base32 seed produced by encoding 20 random bytes (160 bits) according to RFC 4648. Those 20 bytes constitute the private key, also called the seed or shared secret. The estimated entropy of a 160-bit value is so vast that even a cloud server attack running a trillion guesses per second would require 1.7 quintillion times the age of the universe to exhaust the keyspace — making brute force irrelevant. The only realistic threats are a phishing attack that steals the seed or a reused secret, not a gaming PC attack. Base32 encoding is chosen over raw hex because it uses only uppercase letters and digits 2–7, making a manually typed secret far less error-prone. The generator also shows a hex seed representation alongside the base32 output so you can cross-reference both formats during provisioning, with secure storage of the result being your responsibility once copied.

Using Your TOTP QR Image Decoder Output in Apps and Code

Building an OTPAuth URI for QR Code Scanning

Once you have a secret, the standard way to deliver it to users is via qr code import scanning. Apps like Google Authenticator, Authy, and Microsoft Authenticator all understand the otpauth:// URI scheme. To generate QR code assets, construct the otpauth URI in this format and pass it to any QR-rendering library:

otpauth://totp/{provider}:{user}?secret={SECRET}&issuer={provider}&algorithm=SHA1&digits=6&period=30

The provider field names your application (e.g., MyApp); the user field is usually the user's email address. To generate QR and allow users to scan authenticator apps, pipe this URI into a library such as qrcode (Python) or qrcode.js (browser). The tool on this page handles this step for you — fill in the service name and user identifier, click Generate URI, and you get a ready-made import QR codes-compatible image. You can also use the built-in totp qr image decoder tab to verify that an existing QR image encodes the secret you expect — useful for auditing physical security keys before distribution.

To import QR codes into the tool, use the decoder tab, which parses the otpauth:// payload from any scanned image without sending the image or the embedded seed anywhere — values never leave device at any point during decoding.

Code Examples by Language — Implementation Examples

The following implementation examples show how to generate TOTP code and verify code in the three most common server-side runtimes. Each snippet uses the same demonstration secret; replace it with your securely stored value in production.

Node.js implementation using the otplib library:

const { authenticator } = require('otplib');

// Secret stored securely server-side (never log this)
const secret = "JBSWY3DPEHPK3PXP";

// Generate current TOTP code
const code = authenticator.generate(secret);
console.log(code); // e.g., "492039" — a fresh 6-digit code

// Verify user-submitted code (accounts for time drift automatically)
const isValid = authenticator.verify({ token: userCode, secret });
console.log(isValid); // true or false

Python implementation using the pyotp package:

import pyotp

# Store this secret securely for each user — never commit to source control
secret = "JBSWY3DPEHPK3PXP"

# Generate current TOTP code
totp = pyotp.TOTP(secret)
print(totp.now())  # e.g., "492039"

# Verify a code from user
is_valid = totp.verify("492039")
print(is_valid)  # True

# Build a provisioning URI for QR code generation
uri = totp.provisioning_uri(name="[email protected]", issuer_name="MyApp")
print(uri)  # otpauth://totp/MyApp:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=MyApp

PHP implementation using GoogleAuthenticator (via sonata-project/google-authenticator):

use Sonata\GoogleAuthenticator\GoogleAuthenticator;

$ga = new GoogleAuthenticator();
$secret = "JBSWY3DPEHPK3PXP";

// Verify user's submitted code
$isValid = $ga->checkCode($secret, $userCode);
var_dump($isValid); // bool(true)

Each library handles time drift and offset tolerance internally, accepting codes from the immediately preceding and following 30-second intervals to compensate for clock skew between client and server.

Importing Hardware Token Files for Entra ID — 2FA at Enterprise Scale

If your organisation deploys physical hardware tokens rather than (or alongside) phone-based multi-factor verification, this totp toolset supports a direct device-import workflow via the Entra ID hardware-key import format. After generating a batch of secrets, use the CSV export or JSON export button to produce an import file with the required columns — UPN, serial, secret (base32), algorithm, digits, and period — that maps directly to the Microsoft identity platform bulk upload schema. The seed export is performed entirely in the browser, so no secrets touch a remote server during the csv export or json export steps. This approach is ideal for enterprise multi-factor rollouts where physical keys must be pre-provisioned and assigned to specific user profiles before distribution, supporting login hardening at scale.