Start with the original references
RFC 6238 Appendix B contains TOTP test vectors. RFC 4226 Appendix D contains HOTP test values. Use the original documents so you can see the exact assumptions behind each result.
TOTP reference outputs
The following RFC 6238 cases use a 30-second period and eight digits. Use the algorithm-specific sample key bytes in Appendix B; the SHA-1, SHA-256 and SHA-512 keys have different lengths.
| Unix time | SHA-1 | SHA-256 | SHA-512 |
|---|---|---|---|
| 59 | 94287082 | 46119246 | 90693936 |
| 1111111109 | 07081804 | 68084774 | 25091201 |
| 1234567890 | 89005924 | 91819424 | 93441116 |
Check the counter-based example
For the RFC 4226 sample key bytes 12345678901234567890, the Base32 encoding is GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ. With SHA-1 and six digits, counter 0 produces 755224 and counter 1 produces 287082. These keys are public test fixtures. Never use them for a real account.
Keep the inputs consistent
Check the key bytes, timestamp or counter, algorithm, and output length. A displayed Base32 key is an encoding of bytes; it is not necessarily the literal text used as a key in a published test case.
Test outside a live account
Use the published sample secrets only in tests. They are public and must never protect a real account. To test an application further, include malformed inputs, time-window boundaries, leading-zero outputs, and large counter values.
What passing a vector means
Matching a published value checks a particular input and calculation. It does not establish that a whole product, deployment, provisioning flow, or account recovery process is secure.