Security Runs locally Ready to use Built-in examples No tracking

TOTP Code Generator

Paste the Base32 secret from your authenticator app to see the current one-time code, the remaining seconds and the next code. Same algorithm as Google Authenticator (RFC 6238); the secret stays in your browser.

Two-factor codes — six digits, changing every 30 seconds — are TOTP: the authenticator app and the server share a Base32 secret, each divides the current time by 30 seconds to arrive at the same code, and nothing travels over the network. This tool uses the same algorithm as the common authenticator apps (RFC 6238), so pasting a secret shows the current code, the seconds remaining and the next code — useful when the secret is on a computer and the phone is not to hand.

The most common reason a code is rejected is the clock: a local time more than 30 seconds off the server will always compute the wrong code, so enable automatic time sync. Beyond that, confirm the parameters — the great majority of services use the defaults of SHA-1 with six digits and a 30-second period, and only an explicit mention of SHA256, eight digits or 60 seconds calls for a change. The secret deserves the same secrecy as a password: never paste it on a shared computer.

—

—
—
—

How to use

  1. Paste the Base32 secret from the two-factor setup.
  2. Read the current code and the seconds remaining.
  3. Change the algorithm, digit count or period only if the service says so.
  4. Check the clock if codes are rejected, and never paste a secret on a shared machine.

How it works

Basic usage

Paste the Base32 alphanumeric key from your authenticator (A–Z and 2–7, optionally grouped with spaces or hyphens) into the key field, and the code generates instantly with a countdown bar showing seconds until refresh. Two auxiliary values appear below: the next time-slice code (for timing logins) and the current counter.

Troubleshooting mismatched codes

When codes mismatch, check the clock first: TOTP uses "current time ÷ 30 seconds" as input, so drift of more than one period between your machine and the server (or authenticator) produces wrong codes — phone auto-time fixes this. Then check the key itself: stray characters beyond QR-scan spaces, or a partial copy, triggers an "invalid Base32" error. Finally confirm algorithm and digits: a few services use SHA-256, 8 digits or 60-second periods.

Choosing the parameters

The overwhelming standard is "SHA-1 + 6 digits + 30 seconds" — the Google Authenticator default — so keep the defaults. Change only when the server explicitly says "SHA256", "8 digits" or "60 seconds"; a wrong setting produces no error, just codes that never match.

Method: TOTP per RFC 6238 with dynamic truncation per RFC 4226; the secret is decoded as RFC 4648 Base32 (spaces, hyphens and = padding ignored, case-insensitive), the counter is ⌊browser local time ÷ period⌋, and the HMAC uses SHA-1 (default) or SHA-256. Codes are truncated to 6 or 8 decimal digits and left-padded with zeros. Time comes from the local clock, with no network time sync.

Code example

JavaScript Generating with otplib in Node 

// npm install otplib
const { authenticator } = require("otplib");

authenticator.generate("JBSWY3DPEHPK3PXP");  // the current 6-digit code
authenticator.check(code, secret);           // server-side verification

// Defaults to SHA-1 + 6 digits + 30 seconds, in line with mainstream authenticators

Shell Generating on the command line 

# oathtool: brew install oathtool, or apt install oathtool
oathtool --totp -b "JBSWY3DPEHPK3PXP"   # -b means the secret is Base32

# 8 digits with a 60-second period
oathtool --totp=SHA1 -b -d 8 -s 60 "JBSWY3DPEHPK3PXP"

FAQ

How often does the code change? Why do I differ by one or two digits?

Every 30 seconds by default. Off-by-one mismatches are boundary effects: the code flips exactly at second 30, so if you submit with 0.2 seconds left locally and the server receives it in the next slice, a just-generated code is already stale. Submit right after the bar refills; some servers also accept the adjacent slice to tolerate jitter.

It says my key is not valid Base32 — now what?

Base32 allows only A–Z and 2–7 (plus spaces, hyphens and = padding, which the page ignores). Common causes: mistaking 0 for O or 1 for I (those digits don't exist in Base32 — their presence means a bad copy); pasting the whole otpauth:// link; or dropping/adding characters. Re-copy the full key from the QR decode or the server's "show key" view.

What does the QR code contain?

An otpauth://totp/... link with parameters: the secret, issuer, digit count and period. This tool needs only the secret — paste it alone; the full link errors out because slashes and colons aren't legal Base32.

Does phone clock drift affect the code?

Yes — it's the number-one cause of "my code never works". TOTP uses "current Unix time ÷ period" as its counter, so any drift over 30 seconds guarantees errors. Enable automatic time on the phone; servers likewise require NTP sync per ops playbooks.

TOTP vs. SMS codes — what's the difference?

SMS codes are generated server-side and delivered over carrier channels, exposed to interception and SIM-swap attacks. TOTP is computed locally by both sides from a shared key plus the time — it never travels the network, so channel hijacking gets nothing. The trade-off: if the key leaks (say, via a screenshot), anyone can compute codes at any time, so treat the key with password-level secrecy.

SHA-1 is broken — why is it still used for codes?

SHA-1's weakness is collisions — crafting two messages with the same digest. HMAC-SHA1's security rests on "no key, no forgery", which collision attacks don't undermine. Since TOTP is an established protocol and switching requires client and server upgrades in lockstep, SHA-1 remains the default. Where servers support SHA-256, this tool can switch.

Is my key uploaded or saved?

No. Computation is local; the key never reaches a server or browser storage, there's no history section, and refreshing clears everything. Note that even so, pasting a long-lived 2FA secret into any web page carries risk — never do it on shared computers.

Why no SHA-512 option?

RFC 6238 permits SHA-512, but it needs 64-bit integer arithmetic and virtually no authenticator or server uses it — SHA-1 by default, SHA-256 occasionally. Offering only the algorithms actually deployed keeps the output semantics clear and avoids an option you'd never use.