Verifying an authenticator integration during development
Generating a code from a known secret confirms your server's verification logic, window tolerance and base32 decoding are correct.
Security🌐 YAS server-sideAPI availableadvanced
TOTP Generator
Generates the current 6-digit TOTP code for a Base32 secret (RFC 6238).
Processed by YAS · not stored
Ready to runInstant execution
Loading tool…
What does this tool do?
Generates the current 6-digit TOTP code for a Base32 secret (RFC 6238).
Why would I use it?
- You are setting up 2FA manually and need a code now.
- You want to verify a TOTP implementation.
- You lost your authenticator app and have the backup secret.
Real-life example
Input
secret: JBSWY3DPEHPK3PXP
Output
123456 (current 30-second window)
Codes change every 30 seconds.
Input → Process → Output → Next
- Input
- Paste the Base32 secret.
- Process
- YAS computes HMAC-SHA1 over the current time counter.
- Output
- The 6-digit code valid for this 30-second window.
- Next action
- Enter it into the service before it rotates.
Common mistakes
- Using the wrong secret (case/whitespace issues).
- Expecting codes to be valid longer than 30 seconds.
- Sharing secrets with untrusted sites — this tool processes server-side, so only use test secrets.
What the result means
The code is time-based: it changes every 30 seconds.
Privacy & security
Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.
API
Endpoint
POST https://yas.sh/api/v1/tools/totp-generator
Request Header
Content-Type: application/json
cURL
curl -X POST "https://yas.sh/api/v1/tools/totp-generator" \
-H "Content-Type: application/json" \
-d '{"secret":"JBSWY3DPEHPK3PXP"}'JavaScript
const res = await fetch("https://yas.sh/api/v1/tools/totp-generator", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"secret": "JBSWY3DPEHPK3PXP"
}),
});
const data = await res.json();Python
import requests
r = requests.post("https://yas.sh/api/v1/tools/totp-generator", json={"secret":"JBSWY3DPEHPK3PXP"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| secret | string | Yes | Base32 TOTP secret |
Success response
{ "secret": "JBSWY3DPEHPK3PXP", "code": "123456", "secondsRemaining": 12, "period": 30 }Generate the current 6-digit TOTP code from a base32 secret.
Error responses
400 VALIDATION_ERROR— invalid input or unsupported option.413 PAYLOAD_TOO_LARGE— input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED— rate limit exceeded (60 req/min).
Limits
- Maximum input: 64 KB per request.
- Rate limit: 60 requests/min per IP address.
- Authenticated accounts benefit from higher tier quotas.
TOTP Generator: technical reference, use cases and FAQ
How TOTP Generator works
TOTP (RFC 6238) is HOTP (RFC 4226) with a time-derived counter. The counter is floor(unixTime / period), normally a 30-second step. HMAC-SHA1 is computed over that counter with the shared secret, then dynamic truncation selects four bytes from the digest using its last nibble as an offset, and the result modulo 10^6 gives the six-digit code.
Both sides derive the same code from the same secret and the same clock, with no network traffic between them — which is why an authenticator app works offline. It also means clock drift is the dominant failure mode: servers typically accept the adjacent windows (±1 step) to tolerate a small skew, and a device more than a minute out will fail every attempt.
When to use it: real-world scenarios
Diagnosing codes that are always rejected
If the code here matches the user's app but the server rejects it, the fault is server-side — usually clock skew or a mis-decoded secret.
Recovering access to a test account
A shared test account whose authenticator lives on someone else's phone can be reached with the enrolment secret.
Teaching how second factors work
Watching the code change every 30 seconds from a secret and a clock demystifies the mechanism.
Pro tips
- Never paste a production TOTP secret into any web page, including this one. The secret is the second factor; entering it anywhere removes the separation that makes it a second factor at all.
- Sync the server clock with NTP. Almost every 'my codes do not work' report traces to drift on one side.
- Store enrolment secrets encrypted at rest and never log them — a logged secret grants permanent code generation.
- Provide single-use recovery codes at enrolment. Lost phones are far more common than compromised secrets.
Limitations and edge cases
What this tool deliberately does not do, and where it will disagree with other implementations.
- TOTP is phishable: a code entered on a convincing fake site works for the attacker within the same window. WebAuthn/passkeys resist this; TOTP does not.
- SHA-1 is specified by RFC 6238 for compatibility. It is safe in this HMAC construction but cannot be changed without breaking existing authenticators.
- Codes depend on an accurate clock on both sides; there is no negotiation mechanism.
- This page is deliberately ad-free — a second-factor page should not load third-party scripts.
Frequently asked questions
- Why is my code rejected even though it looks right?
- Clock skew, nearly always. TOTP derives the code from the current time step, so a device or server more than 30–60 seconds out produces codes for a different window.
- Is it safe to generate codes here instead of on my phone?
- For test accounts, yes. For real accounts, no — pasting the shared secret into a browser defeats the purpose of having a separate factor on a separate device.
- Why does TOTP still use SHA-1?
- RFC 6238 specifies HMAC-SHA1 and every authenticator implements it. HMAC-SHA1 has no practical weakness in this construction, and changing it would break interoperability.
- Is TOTP as strong as a passkey?
- No. TOTP codes can be phished in real time. WebAuthn/passkeys bind the credential to the origin, which removes that entire attack class.
Related tools