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.
Generate and verify RFC 6238 time-based one-time passwords from a Base32 secret or otpauth URI. The tool supports 6/8 digit codes, 30/60 second periods, current and next window output, countdown timing, and optional code verification. Use it to debug Google Authenticator-compatible login flows, validate backend OTP implementations, or inspect 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:demo@example.com?secret=JBSWY3DPEHPK3PXP&issuer=ToolsKit&period=30&digits=6Current code
Use it for the code that should normally pass right now.
Next code
Use it when a user submits near the rollover boundary and the receiving system allows a small time window.
Note: Seeing both windows makes timing bugs easier to reason about without weakening the actual 2FA policy.
Raw 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 the setup context people often forget to check.
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. Paste a Base32 secret or otpauth URI, generate the current and next code window, then enter a code to check whether it matches.
Q02
Yes. otpauth://totp links are parsed into secret, digits, period, and issuer-style settings so you can sanity-check the setup.
Q03
TOTP codes are time-window based. Most 2FA apps rotate every 30 seconds 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.
Cause: Most consumer 2FA flows use six digits, but some internal systems use eight.
Fix: Match the digits field to the otpauth URI or backend policy before verifying the code.
Cause: Base32 secrets are easy to break when copied from screenshots, docs, or QR decoding tools.
Fix: Remove formatting spaces and verify the secret characters before assuming the authenticator app is wrong.
Goal: Generate and validate a current 2FA code from a Base32 secret or otpauth URI before blaming the login system.
Result: You can tell whether the problem is the secret, timing window, digit length, copied URI, or clock drift.
Goal: Make sure a copied secret still produces the same six-digit code before it is used in docs, QA, or a staging login flow.
Result: You avoid chasing an auth bug when the real issue is a copied character, wrong period, or unsynced clock.
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".
Yes. Paste the code into the verification field and the tool checks whether it matches the current or next TOTP window.
Yes. The tool can parse secret, digits, and period from otpauth:// URIs used by authenticator QR codes.
Yes. It follows RFC 6238 TOTP behavior used by common authenticator apps when secret, digits, period, and time are aligned.
Check the Base32 secret, digits, period, and system time. Clock drift is a common reason for mismatches.
Yes. Current and next code values refresh with the countdown timer.
No. Secret parsing, HMAC calculation, and code verification are fully client-side.
Keep browsing