Random String Generator

What Is a Random String Generator?

A random string generator produces a sequence of unpredictable characters drawn uniformly from a chosen alphabet — letters, digits, symbols, or any custom set. The output is used wherever an application needs a value that an attacker cannot guess: passwords, API tokens, session IDs, password-reset tokens, salt values for password hashing, database record IDs, file upload nonces, and short codes for shareable links.

Not every string that looks random is safe to use. The strength of a random string depends on two things: the size of the alphabet you draw from, and how the generator chooses characters. This tool uses the Web Crypto API's crypto.getRandomValues(), which is a CSPRNG — a cryptographically secure pseudo-random number generator backed by your operating system's entropy source. It is the same primitive that password managers, TLS libraries, and SSH key generators rely on.

CSPRNG vs Math.random() — Why It Matters

JavaScript's Math.random() is a fast, statistically-decent PRNG (V8 currently uses xorshift128+), but it is not cryptographically secure. Its internal state is small enough that, given a few outputs, an attacker can reconstruct the seed and predict every future value. That is fine for picking a random color or shuffling a deck for a game; it is catastrophic for generating a password reset token. Real-world incidents — for example, the 2010 Hacker News password leak — happened because a non-CSPRNG was used to mint security-sensitive tokens.

This tool never calls Math.random(). Every byte of every string comes from crypto.getRandomValues(new Uint8Array(n)), which the browser implements on top of BCryptGenRandom (Windows), getrandom() (Linux), or SecRandomCopyBytes (macOS/iOS). These OS-level CSPRNGs collect entropy from hardware events (interrupts, disk timing, on-chip RNGs) and pass it through a cryptographic mixing function. The output is indistinguishable from true randomness to any computationally bounded attacker.

Entropy: How Strong Is "Strong Enough"?

Entropy measures the unpredictability of a string in bits. For a string of length L drawn uniformly from an alphabet of size N, the entropy is L × log₂(N). Some practical numbers:

• 16 lowercase letters (a–z): 16 × log₂(26) ≈ 75 bits — strong against any non-state-level attacker
• 16 alphanumeric (A–Z, a–z, 0–9): 16 × log₂(62) ≈ 95 bits — solid for human-typed passwords
• 16 alphanumeric + symbols (~94 chars): 16 × log₂(94) ≈ 105 bits — overkill for most threat models
• 32 hex characters (0–9, a–f): 32 × 4 = 128 bits — industry standard for API tokens and session IDs
• 64 hex characters: 256 bits — used for HMAC webhook secrets and high-stakes signing keys

The conventional thresholds: 80 bits is the floor for any security-sensitive token in 2026, 128 bits is the safe default, and 256 bits is what you use when the cost of compromise is enormous (root signing keys, master encryption keys). The entropy badge next to the Generate button shows the current estimate live as you change the length and charset.

Choosing the Right Charset

The smallest charset that meets your entropy goal is usually the right choice — every extra character class adds compatibility headaches without adding much bit-strength. Some practical guidance:

• Hex (0–9, a–f) — best for tokens that travel in URLs, JSON, or HTTP headers. No escaping, no case-sensitivity issues, exactly 4 bits per character.
• Base64url (A–Z, a–z, 0–9, -, _) — denser than hex (6 bits/char) and URL-safe. A 22-character base64url string is 128 bits.
• Alphanumeric (A–Z, a–z, 0–9) — readable, type-able, no escaping issues. Good default for human-shared codes.
• Alphanumeric + symbols — the textbook "strong password" charset. Use it when a policy requires it; otherwise prefer longer alphanumeric strings, which give the same entropy with fewer escaping problems.
• Numeric only (0–9) — short PINs and verification codes. Pair with rate-limiting; entropy per character is low (3.32 bits).

Excluding Look-Alike Characters

When a string will be transcribed by a human — a printed recovery code, a gift card, a one-time setup PIN read aloud over the phone — including I, l, 1, O, and 0 guarantees a percentage of typos. Excluding them costs roughly 0.3 bits of entropy per character (you go from 62 to 57 alphanumeric characters), which is negligible compared with the value of fewer support tickets. Toggle the Exclude similar option whenever a human eye will see the string. Skip it for purely machine-handled tokens — every excluded character lowers entropy slightly without benefit.

Generating the Same String in Code

This tool is convenient for ad-hoc generation, but for production you should generate secrets server-side or in a deploy script using your language's CSPRNG primitive:

// Node.js
const crypto = require('crypto');
crypto.randomBytes(16).toString('hex');       // 32-char hex (128-bit)
crypto.randomBytes(24).toString('base64url'); // 32-char base64url (192-bit)

// Python (3.6+)
import secrets
secrets.token_hex(16)        // 32-char hex (128-bit)
secrets.token_urlsafe(24)    // ~32-char base64url (192-bit)

// Browser / Deno
const a = new Uint8Array(16);
crypto.getRandomValues(a);
Array.from(a, b => b.toString(16).padStart(2, '0')).join('');

// Bash / openssl
openssl rand -hex 16
openssl rand -base64 24 | tr -d '=' | tr '+/' '-_'

Avoid Math.random() in JavaScript, random.random() in Python, and rand() in PHP for any security-sensitive purpose — they are PRNGs, not CSPRNGs, and their output is predictable.

Common Use Cases

• Passwords — 16 alphanumeric+symbol characters, used with a password manager. The "Password" preset.
• API tokens & bearer tokens — 32 hex characters (128-bit) is the industry default. The "API Token" preset.
• Session IDs — 128-bit minimum. Most frameworks generate this for you; if yours doesn't, use this tool.
• Password reset / email verification tokens — 128-bit, single-use, expire after 15–60 minutes. Hex or base64url is fine; URL-safe is recommended.
• Salts for password hashing — 16 bytes (128 bits) of random data, stored alongside each password hash. Never reuse a salt.
• Database record IDs — when sequential auto-increment IDs leak business information (number of users, growth rate), random hex IDs hide it.
• One-time PINs and short codes — 6–8 numeric digits are common for SMS verification. Always rate-limit; entropy is low.
• URL slugs for unlisted content — 8–12 alphanumeric characters give an unguessable share link without making URLs ugly. The "URL Slug" preset.

What This Tool Is Not For

Random strings are not the right primitive for every problem. Use a UUID (try our UUID Generator) when you need a globally unique identifier following RFC 4122 — they are formatted predictably and recognized by databases and middleware. Use a UUIDv7 when you also need lexicographic sort order. Use a JWT for transmitting authenticated claims (try our JWT Decoder). Use a key derivation function (PBKDF2, scrypt, Argon2) when you need to derive a secret from a password — never use a random string in place of a properly hashed password.

For HMAC webhook signing keys specifically, the Webhook Secret Generator formats output for GitHub, Stripe, and Slack out of the box. For raw API tokens with a few format options, use the API Key Generator or the Random Token Generator.