Developer

TOTP Generator

Authenticator-style rotating codes from Base32 secrets.

Loading interactive tool…

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

  1. 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.
  2. 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.
  3. The tool immediately displays the current 6-digit TOTP code for this 30-second window, with a Refresh in counter showing the seconds remaining.
  4. 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.
  5. 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.
  6. 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

Verifying a Base32 secret against an authenticator app

Input
Secret: JBSWY3DPEHPK3PXP
Expected result
Current 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.

Debugging a one-window grace period

Input
Secret: MY2GCZTBORQXEYLS, backend reports 'code expired'
Expected result
Previous, 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.

Extracting secret from a QR code URI

Input
otpauth://totp/Example:user@example.com?secret=ORSXG5A&issuer=Example
Expected result
Paste 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.

Explore the category

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