Starting with a public sample
The string JBSWY3DPEHPK3PXP populated in the input field upon loading is an unencrypted demonstration secret key provided exclusively for testing and observing the mechanics of Time-Based One-Time Passwords (TOTP).
Standard TOTP implementations decode this Base32 secret and evaluate it against the current Unix time divided into 30-second windows using the HMAC-SHA1 cryptographic algorithm to derive a 6-digit code.
Because this demonstration key is public and static, anyone with access to the current timestamp will generate the exact same numerical sequence.
Consequently, you must never utilize this sample key to protect actual accounts or configure real multi-factor authentication systems.
This client-side utility does not store secrets in persistent local storage, does not manage account credentials, and cannot read QR codes via camera.
All evaluations occur purely in the local browser context without sending your entered keys to external servers.
To maintain temporal synchronization, the English interface utilizes the time-step change detection architecture shared with the Japanese version.
Instead of naively assuming execution occurs at every second boundary, each timer invocation compares the current window index calculated as Math.floor(Date.now() / 30000) against the previous recorded step.
When this index changes—whether the exact boundary tick was skipped due to background tab throttling, or the local system clock moved backward—a fresh calculation is promptly initiated.
While the execution loop is scheduled with a 1000ms timer, browser power-management policies mean there is no guarantee of exact scheduling or uninterrupted background updating.
Remaining seconds for the countdown are calculated directly from local system time (Date.now()), so accuracy relies entirely on your device's internal clock rather than an external network time protocol authority.
During active computation, the display shows a temporary ------ placeholder before presenting the calculated code formatted as NNN NNN.
Race conditions from rapid secret modifications, component cleanups, or concurrent requests are mitigated by incrementing an internal requestId that invalidates stale asynchronous calculation promises, though this architectural mechanism cannot guarantee the total absence of transient display states or guarantee compatibility with production authentication endpoints.
Base32 and random keys
A Base32 encoding scheme is generally adopted for TOTP secret keys. Base32 is a standard that represents data using only uppercase letters (A to Z) and some numbers (2 to 7).
The numbers 0 and 1 are not used, but the letters O and I are. Please be careful of misreading and check the string format with the public sample.
This tool normalizes uppercase and lowercase letters and automatically removes whitespace characters from the entered Base32 string before using it for calculation.
It also verifies the validity of trailing padding (= characters), and if inappropriate characters are included, it displays an error message stating "Invalid Base32 key or Web Crypto unavailable." When you press the "Generate random key" button on the screen, it uses the Web Crypto API provided by the browser to generate 160 bits of cryptographically unbiased random data (utilizing the same secure-random and shared totp libraries) and sets it in the input field as a 32-character Base32 string.
In environments where secure random numbers cannot be generated, "Secure random generation is unavailable. Use a browser with Web Crypto support." is displayed.
This feature is for understanding the structure of the key and is not recommended for registering the 32-character generated key to an actual service.
The mechanism of 30 seconds and 6 digits
This tool calculates TOTP using the HMAC-SHA1 algorithm based on the specifications defined in RFC 6238. It uses fixed settings of a "30-second step (update interval)" and a "6-digit code length".
This is the standard configuration used in many common authentication apps (such as Google Authenticator). As a specific processing flow, the number of seconds elapsed since January 1, 1970, is first divided by 30 to calculate the current time step (counter value).
This counter value and the decoded binary data of the input Base32 key are combined to perform a hash calculation using HMAC-SHA1.
According to a specific rule (Dynamic Truncation), 4 bytes are extracted from the obtained 20-byte hash value, converted into a 31-bit integer by removing the most significant bit, and the remainder when divided by 1 million (10 to the 6th power) is calculated to obtain the final 6-digit number.
On the actual screen, to improve visibility, the 6-digit number is displayed separated by a space every 3 digits, like 123 456.
This entire sequence of calculation processes is completed entirely within the browser's internal memory, meaning the input target conversion happens within the browser.
Conditions for matching clock and settings
For TOTP authentication to succeed, the code-generating side (this tool) and the code-verifying side (the authentication server) must have matching secret keys and calculation settings, and the time must fall within the time interval accepted by the verifying side.
These are the "secret key", "calculation algorithm settings", and "current time". This tool is fixed with the settings of HMAC-SHA1, a 30-second interval, and 6 digits.
If the authentication destination requires SHA-256, uses a 60-second update interval, or requires an 8-digit code, the premise for verification will differ from the fixed settings of this tool even if the same secret key is entered.
Also, a common cause of mismatches is "clock drift". TOTP calculates the time step based on the device's local clock. Therefore, even if the time setting on your computer or smartphone is off by a few minutes or even a few tens of seconds, a code for a different time step will be calculated.
Since it strictly depends on the device clock, there is no guarantee of compatibility with actual accounts. If a result different from the expected code is displayed despite entering the correct secret key, first open your device's clock settings, review the settings to ensure it automatically synchronizes with a standard time server on the internet, and then check the calculation results again.
Copy and remaining seconds
Every 30 seconds, the underlying RFC 6238 TOTP algorithm maps the updated time interval to a new 6-digit numerical token. However, because truncated HMAC-SHA1 outputs only span values from 000000 to 999999, it is mathematically possible for a regenerated code to repeat the identical digits across consecutive steps even when a step change occurs.
Recalculation is evaluated on the subsequent timer callback; because the execution loop runs on an ordinary 1000ms browser interval without background-processing guarantees, tab suspension can delay recognition of a newly entered time window until the tab regains focus or the callback executes.
The central countdown progress bar visualizes remaining time based directly on your device's current clock reading, changing its fill color to yellow when 10 seconds or fewer remain, and transitioning to red when remaining duration drops to 5 seconds or less to signal imminent step expiration.
The 6-digit verification code strips whitespace before copying. Wait for confirmation, or use the manual copy field if clipboard access is denied or unsupported.
Codes expire strictly every 30 seconds; if expired during copy, refresh and press copy again without authentication guarantees. Furthermore, if you copy the token when remaining seconds are low, normal network latency, human entry delays, or browser background suspension may cause the current step to elapse before the submission arrives at the destination service.
Because individual authentication servers enforce their own validation windows and clock-drift tolerances, this tool offers no real-service compatibility guarantee.
When the countdown bar indicates limited time remaining, it is strongly advised to pause and allow the next time-step callback to render a fresh code before copying.
Boundaries of secret key protection and authentication functions
The security model of TOTP is established on the major premise that "the secret key is not known to a third party." If the secret key is obtained, anyone can calculate the exact same authentication code from any device.
This tool is strictly a utility for learning and verification to simulate the TOTP calculation mechanism on the browser and check its behavior.
Through the process of converting and calculating the input target key within the browser, the key is not transmitted to external servers.
The key acts as authentication credential information; do not use or transmit production keys as examples. The act of copying and pasting the key as text inherently carries the risk of leakage from clipboard history or shoulder surfing.
Furthermore, this tool does not implement verification functions as an authentication server, QR code reading functions, login functions, or functions for registering 2FA or saving secrets to user accounts.
Please keep in mind that it only provides the result of the hash processing within the browser for the target string, and does not assert the overall communication status of the site or guarantee safety in an actual system.