How long should a random token be? Bits, bytes and encoding

A random access token should carry at least 128 bits, which is 16 random bytes, taken from a cryptographically secure generator. Use more, such as 32 bytes, if the token is long-lived or the cost is trivial. Length counts random bits, not characters on screen.

Count entropy, not characters

A 32-character hex string holds 128 bits, since each hex character carries 4 bits. A 22-character base64url string holds about 128 bits as well, at 6 bits per character. A 16-character lowercase string of letters holds far fewer, around 75 bits.

What matters is how many equally likely values an attacker must try. That depends on the generator, not how long the string looks. A token made from a timestamp plus a counter can look long and hold almost no secrecy.

Sizing guidance

• Sessions, reset links, invitation links: 128 bits is a sound floor. Many teams pick 256 for sessions because it costs nothing.
• API keys that live for months: 256 bits, plus a visible prefix so people can identify a key without revealing it.
• Codes a human types, such as one-time codes: these are short on purpose. Protect them with short expiry, attempt limits and lockouts, since length cannot do the job.
• Anything compared against a stored value: compare in constant time. See constant-time comparison.

Generate it correctly

Use the platform's secure source. OWASP's guidance says a CSPRNG is required for security-critical values and lists examples such as the Python secrets module, Java SecureRandom, Node.js crypto.randomBytes() and getrandom(2) in C. General-purpose generators must not be used for this. Our posts on Python secrets versus random and Go math/rand versus crypto/rand cover two common cases.

Store and handle it

1. Show the token once at creation.
2. Store a hash of it, not the token. A fast hash such as SHA-256 is fine for high-entropy random tokens, because there is nothing to guess; a slow password hash is for human-chosen passwords.
3. Set an expiry and revoke on use or logout.
4. Keep tokens out of logs and URLs where you can. See what never to log.
5. Let people rotate or revoke keys without a support ticket.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how each result names the exact place to fix.

Quick check

Sources

• OWASP Cryptographic Storage Cheat Sheet

Last reviewed: 19 October 2026.