random tokenapi keysession tokensecure randomcryptography

How to Generate Secure Random Tokens for APIs and Sessions

Random tokens power API keys, session IDs, reset links, and CSRF protection. Learn what makes a token secure and how to generate one correctly.

8 min read

Related Tool

Random Token Generator

Open tool

Random tokens are the building blocks of web security. Every API key, session cookie, password reset link, email verification code, OAuth state parameter, and CSRF token is a random value that must be unpredictable to an attacker. Generate them correctly and they are unguessable. Generate them incorrectly and the entire security model collapses.

What Makes a Token Secure

A secure random token has two properties: sufficient length and true randomness.

Length determines the size of the search space. A token made from 32 random bytes has 2 to the power of 256 possible values. Even testing a billion tokens per second it would take longer than the age of the universe to find the right one by guessing.

True randomness means the values are generated by a cryptographically secure pseudorandom number generator (CSPRNG), not a general-purpose random function like Math.random() in JavaScript or rand() in C. A general-purpose random function is predictable if the attacker knows the seed or can observe enough outputs. A CSPRNG produces output that is computationally indistinguishable from true randomness.

Token Formats

A raw 32-byte (256-bit) random value is most commonly encoded as hex (64 characters, each representing 4 bits) or Base64 (approximately 43 characters per 32 bytes, using letters, digits, and two other characters).

URL-safe Base64 replaces the + and / characters with - and _, making the token safe to use directly in URLs and filenames without percent-encoding.

The choice of format does not affect the security of the token; it only affects the characters used to represent the same underlying random bytes.

Common Use Cases

API keys are long-lived tokens (often 32 to 48 bytes) that a client includes in every request to authenticate itself. Store only the hash (SHA-256) of the API key in the database, not the key itself.

Session tokens are shorter-lived (typically 16 to 32 bytes) and identify a logged-in user's session. Store them securely in an HttpOnly, Secure cookie.

Password reset and email verification tokens are single-use tokens (32 bytes) with a short expiration time (15 to 60 minutes).

CSRF tokens are random values embedded in forms to prevent cross-site request forgery attacks.

Using the DevHexLab Random Token Tool

Open the tool at /tools/security/random-token. Choose the number of bytes and the output format. Click Generate. The cryptographically random token appears instantly. Copy it and use it. Generate a new one for every need; never reuse tokens.

Frequently Asked Questions

How long should a token be?

32 bytes (256 bits) is the standard for most security-sensitive tokens. 16 bytes is sufficient for some use cases but provides less margin. Never go below 16 bytes for security tokens.

Can I use a UUID as a security token?

UUID v4 provides only 122 bits of randomness, which is sufficient. However, UUIDs have a distinctive format that reveals their identity. A raw random token is preferable for security applications because it reveals nothing about its origin or format.

Generate fresh, cryptographically random tokens and never reuse them.