Embed this tool on your site
About this tool
TOTP Generator on UtilityKit computes RFC 6238 Time-based One-Time Passwords directly in your browser from a Base32-encoded secret. Paste the secret key shown during 2FA setup, a text string like JBSWY3DPEHPK3PXP (if you only have an otpauth:// URI, copy the value of its secret= parameter), and instantly see the live 6-digit code along with a Refresh in countdown showing how many seconds remain in the current 30-second window. Previous and next window codes are shown alongside the current one so you can confirm a code that is about to expire or test an integration that accepts one window of grace. The tool uses the common authenticator defaults only: HMAC-SHA1, 6 digits and a 30-second step. The HMAC runs client-side via the Web Crypto API; the secret is not sent to a server. Useful for developers building TOTP-based 2FA, QA engineers validating login flows, and sysadmins checking a secret before enrolling it.
Why use it
Instant Debug Aid: Verify that your TOTP implementation produces the correct code without installing a separate authenticator app or configuring a physical device during development.
Fully Client-Side: Your Base32 secret never leaves your browser. All HMAC-SHA1 computation runs locally via the Web Crypto API — no network request is made.
Live Countdown: A Refresh in counter shows the seconds left in the current 30-second window, so you can avoid submitting a code that is about to expire.
Window Inspection: Previous and next codes are displayed alongside the current one, making it easy to test grace-period logic in authentication backends.
Authenticator Defaults: Implements the RFC 4226 / RFC 6238 algorithm with HMAC-SHA1, 6 digits and a 30-second step, the configuration Google Authenticator and Microsoft Authenticator use for most accounts.
No Install Required: Works in any modern browser on desktop or mobile — no app install, no account, no clipboard permission popups beyond what the browser provides.
How to use
- Obtain the Base32 secret from your service. It appears on the 2FA setup screen as a text string like JBSWY3DPEHPK3PXP, or as the secret= parameter inside an otpauth://totp/ QR code URI.
- Paste only the Base32 secret into the Base32 secret field. Spaces and trailing = padding are removed and lowercase is accepted; hyphens or other characters outside A-Z and 2-7 show an Invalid Base32 character error.
- The tool immediately displays the current 6-digit TOTP code for this 30-second window, with a Refresh in counter showing the seconds remaining.
- Use the Previous and Next boxes to see the codes for the window just before and just after the current one, helpful when a service accepts a one-window grace period.
- To test your implementation, compare the displayed code with your authenticator app using the same secret; they must match digit-for-digit at the same moment.
- Click Copy current to copy the active code into a login form or test harness.
When it helps
- When building a 2FA login flow and you need to generate test codes without unlocking a phone or switching apps.
- When debugging a TOTP mismatch — use previous/next windows to identify a clock-skew or off-by-one-window bug in your backend.
- When onboarding a new service that shows a Base32 secret manually and you need to verify it generates the expected code before enrolling your authenticator app.
- When you need a quick code to paste into a CI/CD pipeline that requires 2FA — without storing the secret in a separate secrets manager just for one test run.
- When checking that your server and this tool agree on the current, previous and next code for a test secret at the same moment.
- When a team member needs a code from a shared service secret and you want to generate it securely in-browser without copying it to a messaging app.
Examples
01Verifying a Base32 secret against an authenticator app
InputSecret: JBSWY3DPEHPK3PXP
Expected resultCurrent shows a 6-digit code that changes every 30 seconds (at Unix time 0 this secret gives 282760). It matches an authenticator app using the same secret, SHA-1, 6 digits and 30 s at the same moment.
02Debugging a one-window grace period
InputSecret: MY2GCZTBORQXEYLS, backend reports 'code expired'
Expected resultPrevious, Current and Next show three 6-digit codes for the surrounding windows. If the backend accepts only the Previous code, its clock runs about 30 s behind.
03Extracting secret from a QR code URI
Inputotpauth://totp/Example:user@example.com?secret=ORSXG5A&issuer=Example
Expected resultPaste only ORSXG5A into the Base32 secret field (the full URI is rejected as an invalid Base32 character); a live 6-digit code appears with the Refresh in countdown.
Tips
- If your code doesn't match your authenticator app, check that your computer's clock is synced. On macOS run 'sudo sntp -sS time.apple.com'; on Linux 'timedatectl status' shows NTP sync state.
- Base32 secrets from QR codes can be extracted by scanning with a QR decoder tool — look for the 'secret' query parameter in the otpauth:// URI.
- Add 30 seconds of lead time when automating login flows: generate the next-window code (visible in the Next panel) just before the window rolls to avoid a race condition.
- Never paste production 2FA secrets into untrusted web tools. This tool is browser-only, but always verify the URL is the real UtilityKit site and not a phishing clone before entering any secret.
- TOTP secrets are reusable — unlike passwords, regenerating a code from the same secret always works. Back up your Base32 secrets in an encrypted password manager so you are never locked out.
Frequently Asked Questions
Is my Base32 secret sent to the server?⌄
No. The entire TOTP computation — HMAC-SHA1, counter derivation, truncation, and modulo — runs in your browser using the Web Crypto API and JavaScript. Nothing is transmitted to any server.
Why does my code differ from my authenticator app?⌄
TOTP codes are time-dependent, so both devices must have accurate clocks. A clock skew of more than 30 seconds will produce a different window. Check your system clock is synced via NTP. Also confirm you are using the same Base32 secret, and that the service uses 6 digits, SHA-1 and a 30-second period; this tool cannot change those settings.
What is a Base32 secret and where do I find it?⌄
The Base32 secret is a string of 16–32 characters using letters A–Z and digits 2–7, provided by the service when you enable 2FA. It is shown on the 2FA setup page either as text (for manual entry) or encoded inside a QR code under the 'secret' parameter of an otpauth:// URI.
What is the standard for TOTP?⌄
TOTP is defined in RFC 6238, which extends HOTP (RFC 4226). It applies an HMAC to a counter derived from the current Unix time divided by a time step, then truncates the result to a short numeric code. The RFC allows SHA-1, SHA-256 or SHA-512 and other digit counts; most authenticator accounts use SHA-1, 30 seconds and 6 digits, which is what this tool computes.
Why are three codes shown instead of one?⌄
Many authentication backends accept codes from the previous and next 30-second windows to handle minor clock skew and network latency. Showing all three lets you test grace-period handling or submit the next code when the current one is about to expire.
Can I use this for HOTP (counter-based) tokens?⌄
This tool implements the time-based TOTP variant only. Counter-based HOTP requires a stateful counter stored on both the server and client, which is not supported here. Use a dedicated HOTP library if you need counter-based OTPs.
Can I set 8 digits, a 60-second period, SHA-256 or a custom time?⌄
No. The digits (6), period (30 seconds) and hash (SHA-1) are fixed, and codes are always computed for your device's current clock. Secrets whose otpauth URI specifies digits=8, period=60 or algorithm=SHA256 will not match this tool.
Does this work for Google Authenticator, Authy, and Microsoft Authenticator secrets?⌄
For accounts that use the default 30-second, 6-digit, SHA-1 settings, yes: entering the same Base32 secret gives the same codes. Some services configure 7 or 8 digits or a different period, and those codes will not match.
Is 6-digit TOTP secure enough for production?⌄
TOTP significantly increases account security over passwords alone. The 30-second window and secret-binding make brute force impractical in real time. For production systems, also enforce rate limiting on OTP attempts, use HTTPS throughout, and store the Base32 secret encrypted at rest.
Glossary
- TOTP
- Time-based One-Time Password — a 6-digit code generated from a shared secret and the current time, valid for a single 30-second window. Defined in RFC 6238.
- HOTP
- HMAC-based One-Time Password — the counter-based OTP algorithm defined in RFC 4226 that TOTP extends by replacing the counter with a time-derived value.
- Base32
- An encoding scheme (RFC 4648) using uppercase letters A–Z and digits 2–7 to represent binary data as printable ASCII. TOTP secrets use it because it is case-insensitive and leaves out the digits 0, 1, 8 and 9, which are easy to confuse with O, I and B.
- HMAC-SHA1
- Hash-based Message Authentication Code using the SHA-1 hash function. TOTP uses HMAC-SHA1 to combine the shared secret and time counter into a verifiable digest before truncation.
- Time Step
- The interval in seconds over which a TOTP code is valid. The RFC 6238 default is 30 seconds, meaning the code changes every 30 seconds based on Unix time divided by 30.
- otpauth URI
- A standardised URI scheme (otpauth://totp/Label?secret=BASE32&issuer=Name) used to transfer TOTP credentials via QR code to authenticator apps. Scanning this URI with an app registers the secret automatically.
A LITTLE HELP. A LOT DONE.
Good tools.
Great flow.
Your shortcut to the everyday. Create, convert, calculate,
and get back to what you love.
✳
✳
✓ Free to use✓ No sign-up✓ 500+ possibilities