Random String Generator — Custom Length & Character Set

Standard programming language functions such as JavaScript's Math.random(), Python's random.random(), and PHP's rand() produce pseudo-random numbers using deterministic algorithms seeded from a relatively small initial value. While they appear random, their output can be predicted if the seed or internal state is known. This makes them unsuitable for security-critical applications such as session tokens, password reset links, and API keys. Cryptographically secure pseudo-random number generators (CSPRNGs) draw entropy from operating system sources such as /dev/urandom on Unix-like systems and BCryptGenRandom on Windows, which accumulate unpredictable data from hardware events like network timing and keystroke intervals. This makes CSPRNG output computationally infeasible to predict. This tool uses window.crypto.getRandomValues() in the browser, which is backed by the OS CSPRNG and meets the security bar for generating tokens and credentials.

The security of a random string depends on two factors: length and character set size. Entropy is measured in bits and calculated as: entropy = length multiplied by log2(charset_size). A 32-character alphanumeric string using 62 characters (a-z, A-Z, 0-9) has approximately 190 bits of entropy, which is more than sufficient for any current security purpose. Adding symbols expands the character set to about 94 printable ASCII characters, increasing entropy to roughly 204 bits per 32-character string. For comparison, a 128-bit AES key provides 128 bits of security, and 128 bits of entropy is generally considered the minimum for long-term security. A 22-character alphanumeric string already exceeds 128 bits. Longer strings and larger character sets provide more entropy, but even a 16-character alphanumeric string at 95 bits is strong for session tokens given their short lifetimes.

API keys are long-lived credentials that identify and authenticate a client. They should be generated with at least 128 bits of cryptographic entropy — roughly 22 or more alphanumeric characters. A common format is a prefix that identifies the service or key type (such as "sk_live_") followed by a long random string, making keys easy to identify in logs and configuration files without compromising security. Avoid using sequential IDs, UUIDs alone (which are not secrets), or encoded user IDs as API keys since they do not provide the necessary entropy or unpredictability. Store API keys hashed (SHA-256) in your database, just like passwords — this way, a database breach does not immediately expose valid credentials. When an API key is issued, it should be shown to the user only once and never stored in plain text on the server.

Password reset tokens, email verification links, and one-time codes must be unguessable and single-use. Generate them with a CSPRNG using at least 128 bits of entropy (22 or more alphanumeric characters, or 32 or more hex characters). Store only a hash of the token in the database, not the raw value. Associate each token with a specific user ID and an expiration time, typically 15-60 minutes for password reset and 24 hours for email verification. When the user submits the token, compare it against the stored hash using a constant-time comparison function to prevent timing attacks. Immediately invalidate the token after successful use to prevent replay attacks. Never include these tokens in server logs or error messages where they could be exposed to parties other than the intended recipient.

Session identifiers must be random enough that an attacker cannot guess a valid session by brute force. OWASP recommends at least 128 bits of entropy for session IDs. Modern web frameworks such as Express.js, Django, Laravel, and Rails generate cryptographically random session IDs by default, but if you are building a custom session system, use a CSPRNG such as crypto.randomBytes() in Node.js or os.urandom() in Python. CSRF tokens should be unique per session and per form submission, generated with a CSPRNG, embedded in forms as hidden fields, and verified on every state-changing request. A CSRF token does not need to be extremely long since 128 bits is sufficient, but it must be tied to the authenticated session and validated server-side on every mutation request.