About this tool
A TOTP code is the six-digit number an authenticator app shows after your password — the second factor in two-factor authentication — and it changes every 30 seconds because it is computed from a shared secret and the current time, not from any connection. This tool computes those codes locally in your browser: paste a Base32 secret or an otpauth:// URI — the kind a QR code from Facebook, Telegram, Gmail or a bank encodes — and it shows the current code with a countdown until the next one, plus a decoder that reveals which issuer, account and parameters a URI actually contains. Use it to check a migration between phones, to test a secret you just set up, to inspect a URI before trusting it, or to learn how 2FA works. Do not use it as your everyday authenticator: a TOTP secret pasted into any website — including this one — is a credential exposed to whatever runs in that browser tab, so the safe use is testing, migration checks and learning, not daily sign-in. A dedicated authenticator app on your own phone remains the right place for live secrets.
How it works
Everything happens in two files you can read: web-static/lib/totp/totp.ts and two-fa-code-generator-client.tsx. Paste a bare Base32 secret and the page validates it character by character (validateBase32); paste an otpauth:// URI and parseOtpauthUri splits out issuer, account, secret, algorithm, digits and period — rejecting HOTP URIs, because the counter-based variant is not supported. With a bare secret you can switch SHA-1, SHA-256 or SHA-512, 6 or 8 digits, and a 30- or 60-second window; a URI supplies its own parameters. Every second the client recomputes generateTotpFromSecret: the current Unix time is divided by the period to get a counter, an HMAC over that counter is signed with crypto.subtle using your decoded secret as the key, and the standard dynamic-truncation step picks the digits. That division is why the code changes at each window boundary — and why a device clock that is wrong produces wrong codes. The secret exists only in page memory: reloading or closing the tab removes it, and it is never written to storage or sent in a request.
Use cases
- Checking that a newly set-up authenticator app produces the same code as the secret the service just displayed.
- Migrating 2FA to a new phone: confirming a backed-up secret still generates correct codes before wiping the old device.
- Decoding an otpauth:// URI from a QR image to see which issuer, account and parameters it contains before importing it.
- Reading a code from a recovery secret when the phone holding the authenticator is broken, lost or being repaired.
- A developer in Cambodia or abroad verifying that a service’s TOTP enrolment emits well-formed otpauth:// URIs and standard parameters.
- Learning how two-factor codes actually work by watching the algorithm, digits and period change the output.
Frequently asked questions
Why does the code change every 30 seconds?
TOTP is clock-based, not connection-based. The algorithm divides the current Unix time by the period — 30 seconds by default — and feeds that counter together with your secret into an HMAC signature. When the counter ticks over, a different code falls out. The code works offline for exactly the same reason: nothing is fetched, your device’s clock and the secret are the only inputs.
My code does not match my authenticator app — what is wrong?
The most common cause is clock skew: TOTP uses the device clock, so if your computer’s time is off by more than a step, the same secret yields a different code than on your phone. Sync the clock and the codes realign. After that, check the parameters — the algorithm (SHA-1, SHA-256 or SHA-512), digits (6 or 8) and period (30 or 60) must match what the service issued, which a pasted URI already carries.
Is it safe to paste a real TOTP secret into this page?
Treat it as a decision with consequences. A live secret pasted into any website — including this one — is exposed to whatever runs in that browser tab and to anyone else who uses the device, so the right uses are testing, migration checks and learning, not day-to-day authentication. Keep live secrets in a dedicated authenticator app, and if a secret you relied on was pasted somewhere shared, treat it as compromised and rotate it.
Is this a replacement for an authenticator app?
No. It is a reader and decoder for secrets and URIs — a convenience for the situations listed above — not a credential store. Nothing is persisted: reloading the page loses the secret, there is no encrypted storage, no backup and no device lock protecting it. An authenticator app keeps secrets in hardened, encrypted storage behind your phone’s lock screen, which a web page cannot offer.
Does the secret I paste leave my browser?
No. Generation runs on crypto.subtle inside the page, and the secret lives only in the page’s memory — you can confirm it by opening your browser’s developer tools, filtering the network tab on "all", and watching while you paste and generate: no request carries it. The page records anonymous usage events such as "a URI was parsed", which never include the secret itself.
What do the issuer and account fields in a decoded URI mean?
They are display labels the issuing service packed into the URI — the issuer is the service name (for example "Facebook") and the account is your identifier there. They help your authenticator app list the entry; they do not affect the codes. Only the secret, algorithm, digits and period change what number is produced.
Why does the tool reject a counter-based (HOTP) URI?
The tool implements TOTP only. An otpauth://hotp URI encodes a counter that must stay synchronised between you and the service — a different algorithm (RFC 4226) with different failure modes — so rather than half-support it, the parser rejects it cleanly. Nearly every consumer service issues TOTP URIs, so this rarely comes up.
Does this connect to a Cambodian bank or Bakong?
No. This page does not contact ABA, Bakong or any bank, and it cannot approve a login or payment. It only calculates a TOTP from a secret or otpauth URI you provide. It works for an account only when that service explicitly issues TOTP credentials. Follow the provider’s own enrolment instructions, and keep live bank secrets in an approved authenticator app.
Data and accuracy
TOTP is defined by IETF RFC 6238 on top of the HOTP algorithm in RFC 4226; the otpauth:// URI format is the de-facto Google Authenticator key-URI convention. RFC 6238 section 6 is also the basis for the clock-skew note — it defines resynchronisation precisely because client clocks drift. Computation uses the browser’s crypto.subtle; no external data is fetched, so there is nothing to refresh.
Sources
Content last reviewed 21 October 2026