How TOTP actually works
Time-based one-time passwords (RFC 6238) are simpler than they look: the current Unix time is divided by the period (almost always 30 seconds) to get a counter, the counter is HMAC-SHA1-signed with the shared secret, and a few bytes of the result are truncated into a 6-digit number. Both sides can compute it independently (no network needed) which is why authenticator apps work in airplane mode, and why this page can generate valid codes entirely in your browser.
Legitimate sysadmin uses
The everyday case is debugging: verifying that a secret provisioned into a password manager, a CI pipeline, or a service account actually produces the codes the server expects, or testing your own application's 2FA implementation against a known-good generator. It's also a rescue hatch when you have a secret backed up as text (from the otpauth:// URI's secret= parameter) and no phone at hand.
Handle secrets like the keys they are
A TOTP secret is not a code; it is the permanent key that generates all future codes. Anyone who obtains it has cloned your second factor. So: only paste secrets you own, prefer doing so on a trusted machine, and treat any secret that has touched a clipboard manager or screenshot as potentially exposed. This page stores nothing and transmits nothing (verify with devtools), but the same cannot be assumed of arbitrary online generators, which is precisely why a client-side one is worth bookmarking.
When codes are "wrong"
Ninety-five percent of TOTP failures are clock drift. Codes depend on both clocks agreeing within a window; if a server rejects valid codes, check NTP on the server before suspecting the secret. The rest are usually a mistyped Base32 secret (it never contains 0, 1, 8 or 9) or a non-default digit count or period.