Generate time-based one-time passwords
Quick CTA
Enter a Base32 secret or otpauth URI first to generate the current TOTP immediately; parameter notes stay in Deep.
ββ0s0Next step workflow
Deep expands pitfalls, recipes, snippets, FAQ, and related tools when you need troubleshooting or deeper follow-through.
Use this tool to generate RFC 6238 time-based one-time passwords from a Base32 secret or an otpauth URI. It supports common authenticator settings such as 6/8 digits and 30/60 second periods, and shows both current and next code with countdown. This is useful when debugging login flows, validating backend OTP implementations, or verifying issuer onboarding links. All HMAC operations run locally in the browser.
Bad input: Copying `JBSW Y3DP EHPK 3PXP` directly from docs/email with spaces and mixed formatting.
Failure: Generated OTP does not match authenticator app, leading teams to blame backend verification.
Fix: Normalize the secret to clean Base32 (no hidden whitespace) before any code comparison.
Bad input: Verifying TOTP on a laptop with unsynced time while production servers are NTP-synced.
Failure: Valid secrets appear broken because code windows are shifted by tens of seconds.
Fix: Confirm client/server time sync first, then test with current and adjacent time windows.
Bad input: Server and client clocks differ by over one time step.
Failure: Users enter valid app codes but server rejects them repeatedly.
Fix: Allow small time-step tolerance and enforce NTP health monitoring.
Bad input: Raw TOTP secrets are persisted directly in application database.
Failure: Database leak enables large-scale OTP compromise.
Fix: Encrypt secrets at rest and restrict decryption path to auth service.
Bad input: Verification endpoint allows infinite retries without throttle.
Failure: Brute-force probability rises and abuse detection is weak.
Fix: Add per-account and per-IP rate limits with lockout policy.
Recommend: Use TOTP generator with explicit secret/period/digits and compare with server logs by timestamp.
Avoid: Avoid testing with unknown defaults or unchecked local time settings.
Recommend: Use `otpauth://` URI + QR flow for user onboarding and reserve raw secret view for recovery paths.
Avoid: Avoid exposing raw secrets in routine UI steps where screenshots/clipboard leaks are likely.
Recommend: Validate secret provisioning, time sync, and recovery paths together.
Avoid: Avoid enabling mandatory 2FA without clock-drift contingency design.
Recommend: Unique secret per account, encrypted storage, and retry limits.
Avoid: Avoid shared seeds or unlimited verification attempts.
Recommend: Simplified setup can be used with explicit disposable scope.
Avoid: Avoid promoting demo MFA shortcuts into production auth stack.
txt
otpauth://totp/ToolsKit:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=ToolsKit&period=30&digits=6Raw secret
Use it when the secret is already extracted and you only need code generation.
otpauth URI
Use it when you want the full TOTP configuration in one transportable string.
Note: The secret is enough to generate codes, but the URI carries more setup context.
Multi-app check
Use for public product enrollment flows.
Single-app check
Use only for internal prototypes.
Note: Interoperability testing prevents support-heavy rollout regressions.
Per-user secret
Use for all real user authentication systems.
Shared secret
Use only for temporary lab devices under strict control.
Note: Shared secrets destroy individual accountability and revocation control.
Q01
Yes. It can parse the secret and timing parameters so you can sanity-check a TOTP setup quickly.
Q02
TOTP codes are time-window based, so they rotate on purpose to limit replay usefulness.
Cause: TOTP depends on current time alignment, so clock drift can make good secrets look broken.
Fix: Confirm device and system time are synced before judging the code mismatch.
Goal: Generate a current code from a secret or otpauth URI to confirm the setup looks correct.
Result: You can spot formatting or timing mistakes before blaming the auth system.
Goal: Verify generated secrets produce consistent OTPs on major authenticators.
Result: MFA onboarding issues are caught before customer rollout.
Goal: Confirm authenticator apps generate consistent one-time codes.
Result: 2FA activation flow becomes predictable across client devices.
Goal: Enable TOTP onboarding with recovery and support workflows ready.
Result: MFA activation is secure and supportable at scale.
Goal: Reduce false MFA failures caused by device time skew.
Result: Login friction drops without weakening security posture.
TOTP Generator is most reliable with real inputs and scenario-driven decisions, especially around "Debugging real MFA failures across web/app/backend".
TOTP is a time-based one-time password standard used by authenticator apps for two-factor authentication.
Yes. The tool can parse secret, digits, and period from otpauth URIs.
Check that secret, period, digits, and system time are aligned between both sides.
No. TOTP is generated from a shared secret and time step, while SMS OTP is server-delivered.
Yes. Current and next code values refresh with the countdown timer.
No. Secret parsing and code generation are fully client-side.