TOTP Code Generator
Turn a base32 secret or an otpauth:// URI into the current six-digit code, with the countdown to the next one. Runs in this browser, stores nothing, uploads nothing.
- Runs entirely in your browser
- Nothing uploaded, nothing stored
- No signup
A base32 secret — spaces and letter case are ignored — or a full otpauth://totp/... URI, which carries the issuer and every parameter with it.
Current code
Derived on this page from your clock. The service computes the same digits from its own.
Current code
------
Waiting for the clock
This runs in your browser
- Everything happens in this tab. What you paste is never sent to Sendwin or to anyone else.
- What you paste is never written to local storage, session storage, a cookie or the address bar.
- Nothing from this tool is printed to the browser console.
- Close or reload the tab and your input is gone.
The code is derived with the browser's own Web Crypto implementation, which needs a secure context — that is why this page is served over HTTPS.
Use this to check a seed, not to hold one
Nothing is stored here, which is the point: you would have to paste the seed again on every login, and a second factor you keep copying around is not much of a second factor. Verify a key here, then keep it in a password manager, or in Sendwin's per-profile TOTP vault so the code is generated inside the same profile that performs the login.
Now give every account its own device.
A clean browser is still one browser. Sendwin runs each profile in isolation with its own fingerprint, cookies and proxy, so the accounts you work on never look like they came from the same machine.
- Isolated profiles, each with its own fingerprint and cookies
- A proxy per profile, with the timezone bound to the proxy country
- Windows, macOS and Linux — plus cloud sessions when you need them
The free plan includes 10 minutes of cloud browsing a day.
A one-time code is arithmetic, not a message
A time-based one-time password is arithmetic, not a message. When you scan a 2FA QR code, the site and your authenticator end up holding the same secret. From then on both sides take the current time, cut it into thirty-second steps, run an HMAC over the step number with that secret and truncate the result to six digits. Nothing is transmitted, which is why an authenticator works in airplane mode and why the algorithm is fully specified in RFC 6238. This page is that algorithm, implemented on the page, with a countdown to the next window.
The secret is used in memory and nowhere else. It is not uploaded, not written to localStorage, sessionStorage or IndexedDB, not put in the address bar, and not logged to the console — close the tab and it is gone. Use this to confirm a seed is correct: after migrating between authenticators, when a QR code will not scan, or when you want to know whether a backup you wrote down is the right one. For anything you need tomorrow, keep the seed in a real password manager or in Sendwin's per-profile TOTP vault, where it lives with the account it belongs to.
How the code is actually derived
The secret arrives as base32 and is decoded to bytes. The current Unix time is divided by the period — thirty seconds by default — to give a counter, which is written as an eight-byte value and run through HMAC, normally with SHA-1. A dynamic truncation step picks four bytes out of that digest using its own last nibble as an offset, masks off the top bit, and takes the result modulo one million to produce six digits. The server computes exactly the same thing from its own clock. Change the secret, the period, the digit count or the hash and the output changes completely.
Why a code that looks right gets rejected
Nearly always clock drift. Your device and the server each derive a counter from their own clock, so if the two disagree by more than half a minute you are computing codes for a step the server has already passed or has not reached. Most implementations allow a window of one period either side, roughly thirty seconds of tolerance in each direction, and reject anything beyond it. The fix is to synchronise the system clock rather than to retype the code. The other causes are mechanical: a mistyped secret, or an issuer using a sixty-second period, eight digits or SHA-256 while you generate the defaults.
Where the seed should actually live
The seed is the entire second factor and it does not rotate. Anyone who copies it can generate valid codes indefinitely, from anywhere, without touching your account first, and unlike a password there is no reset that quietly invalidates the old one — you have to re-enrol. So it does not belong in a note, a spreadsheet, a screenshot of a QR code or a chat thread. Keep it in a password manager, or in Sendwin's per-profile TOTP vault so the code is generated in the same profile that performs the login. Use this page to check a seed, then close it.
How to check a seed
- 1
Paste the secret or the URI
Either a base32 secret, where spaces and letter case are ignored, or a full otpauth://totp/... URI, which already carries the issuer, period, digit count and algorithm so nothing has to be set by hand.
- 2
Read the code and the countdown
You get the six digits for the current window and the seconds left in it. If only a moment remains, wait for the next window rather than submitting a code that expires while you are typing it.
- 3
Confirm it against the service
Enter it where you enrolled. Accepted means the seed is right and both clocks agree. Then close the tab — nothing was saved here, so there is nothing to clear afterwards.
Other free checks
A code is one half of getting back into an account. These cover the session and the browser around it.
TOTP FAQ
Why the code rolls every thirty seconds, why a correct-looking code gets rejected, and where the seed should actually live.
Time-based One-Time Password, the standard behind Google Authenticator, Authy, 1Password and the six-digit codes most sites use for two-factor authentication. It is defined in RFC 6238. You and the service share a secret once, at enrolment, and afterwards both sides derive the same short code from that secret and the current time. No code is ever sent between you, which is why it works offline.
Because time is the only thing the two sides share besides the secret. Cutting the clock into thirty-second steps gives both a counter they can compute independently, and rolling it that fast keeps the value of a stolen code close to zero — by the time someone reads it off your screen and types it, it has usually expired. Thirty seconds is the default in the specification; a few issuers use sixty, and a generator has to be told which.
Usually your clock. The server computes the code for its own thirty-second step and typically accepts one step either side, so a device more than about half a minute out of sync produces codes that are arithmetically correct for the wrong window and are refused every time. Sync the system clock and it fixes itself. If the clock is fine, check the parameters: a wrong period, digit count or hash algorithm produces valid-looking codes that are never right. Some services also refuse a code that was already used within its window.
Whichever the service specified, which for the overwhelming majority is SHA-1, the default in the specification. SHA-1's weakness is collision resistance, which HMAC in this construction does not depend on, so it is not a practical problem here. What matters is agreement: generating with SHA-256 against a service expecting SHA-1 gives six digits that are wrong every time, with no error message that says so. If your otpauth URI names an algorithm, use that and nothing else.
The page computes locally: the secret stays in memory, is never sent to us, is never written to localStorage, sessionStorage, IndexedDB or the URL, and is never logged. You can verify that by watching the network tab, or by going offline — the codes keep generating. That said, the honest advice is to treat any web page as a test bench. Paste a seed you are actively verifying, on a machine you trust, and keep the long-term copy in a password manager or in Sendwin's per-profile TOTP vault.
No, and it is deliberately built so you cannot. Nothing is stored, so you would have to paste the secret again on every login, which means keeping it somewhere loose and handling it constantly — the opposite of what a second factor is for. Use this to check that a seed is right, and an authenticator or a password manager to hold it.
It is what a 2FA QR code actually contains. The string looks like otpauth://totp/Issuer:account?secret=BASE32&issuer=Issuer&algorithm=SHA1&digits=6&period=30, and it packs the account label together with every parameter a generator needs. Scanning a QR code is nothing more than reading that text, which is why pasting the URI here gives the same result as scanning it — and why a screenshot of a QR code is exactly as sensitive as the secret itself.
Still have questions? Talk to us →
This is a check, not a backup
This page generates codes from what you paste and nothing more. It cannot tell you whether a seed belongs to the account you think it does, whether the service will accept the result, or whether your enrolment succeeded — only the service can confirm that. And because nothing is stored here, nothing here is a backup: keep the recovery codes the service gave you, since losing the seed with no recovery path usually means an identity check with support.
Keep the code next to the login it belongs to.
Sendwin gives every profile its own TOTP vault, so the second factor is generated inside the same isolated profile that holds the cookies and the proxy for that account. Free for 30 days on Windows, macOS and Linux.
30-day free trial · $0 today · cancel anytime — your profiles stay on your machine