Random Token Generator

How random tokens are generated

Random tokens are generated using the browser's crypto.getRandomValues() method, which accesses the operating system's cryptographically secure random number generator. A buffer of 32-bit unsigned integers is filled with true random values, then each value is mapped through a modulo operation to the chosen character set to produce the final token string.

Using a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) is essential — unlike Math.random(), which uses a predictable deterministic algorithm, crypto.getRandomValues() draws from hardware entropy sources that cannot be predicted even with full knowledge of the system state.

Token entropy by length and character set

Higher entropy means more security. Here is how length and character variety affect the bits of entropy.

How to use Random Token Generator

Random vs pseudo-random

The difference between random and pseudo-random number generation is critical for security. Pseudo-random number generators (PRNGs) like Math.random() use deterministic algorithms that produce numbers based on an initial seed value. If an attacker can determine the seed, they can predict every number generated afterward. PRNGs are fine for simulations and games but completely unsuitable for security tokens.

Cryptographically secure random number generators (CSPRNGs) like crypto.getRandomValues() gather entropy from system sources — hardware random number generators, interrupt timing variations, and other unpredictable environmental noise. These sources provide true randomness that cannot be predicted even with full knowledge of the algorithm. CSPRNGs are required for any security-sensitive application.

Entropy per character set

Each character set contributes a specific number of bits of entropy per character position. Lowercase letters (26 options) contribute log₂(26) ≈ 4.7 bits each. Uppercase letters add another 26 options. Digits (10 options) contribute 3.32 bits each. Symbols (typically 32+ options) contribute about 5 bits each. When combined, a token using all sets has 95 possible characters per position, giving 6.57 bits per character.

To calculate total entropy: multiply the length by the bits-per-character for your chosen set. A 32-character token using all 95 characters has 32 × 6.57 = 210 bits of entropy. This is astronomically secure — far beyond what any practical attack could overcome. Even a 16-character token with all sets (105 bits) would take billions of years to brute force.

Why browser crypto matters

The Web Crypto API (crypto.getRandomValues()) provides direct access to the operating system's secure random number generator. On Linux, this reads from /dev/urandom — the same entropy source used by OpenSSL and SSH. This means tokens generated in the browser are just as secure as those generated by command-line tools like openssl rand.

Unlike server-side generation, browser-based token generation has the advantage of keeping secrets local. Tokens never traverse a network, are never logged on a server, and cannot be intercepted in transit. This makes browser-based generation ideal for scenarios where you need to create secrets for your own applications without exposing them to third parties.

Security best practices for tokens

When using generated tokens, follow these security practices: always hash tokens before storing them in your database (using SHA-256), so a database breach doesn't expose active tokens. Use rate limiting on token validation endpoints to prevent brute-force guessing. Implement token expiration and rotation policies. Never log full tokens in your application logs — log only the first few characters for debugging.

For API keys specifically, consider using a prefix to identify the key type and owner (e.g., sk_live_... for Stripe-style keys). This makes key management easier and allows revocation of specific keys without affecting others. Always provide a way for users to revoke and regenerate their tokens through your application interface.

Frequently asked questions