Random String Generator

Generate cryptographically secure random strings — tokens, API keys, passwords, slugs, and more. Processing done server-side with PHP's random_int().

Length
Count
Character Set

Frequently Asked Questions

PHP's random_int() and random_bytes() use the operating system's CSPRNG (cryptographically secure pseudo-random number generator). While modern browsers also expose crypto.getRandomValues(), server-side generation ensures the randomness is never exposed to client-side JavaScript that could be intercepted by browser extensions or scripts on the page.
Hex strings (0–9 a–f) are URL-safe and often used for session tokens, CSRF tokens, and API keys. A 32-character hex string contains 128 bits of entropy (since each hex digit encodes 4 bits), which is widely considered sufficient for security tokens.
A CSPRNG draws entropy from the operating system's entropy pool (hardware noise, interrupt timing, CPU jitter) and produces output computationally indistinguishable from true random data. A regular PRNG (like Math.random() or rand()) uses a simple algorithm seeded with a predictable value — fast and sufficient for simulations, but never safe for security tokens. PHP's random_bytes() and random_int() both use the OS CSPRNG.
Entropy measures unpredictability in bits. For a random string: entropy = log₂(charset_size) × length. A 32-character string from a 62-character alphanumeric charset has log₂(62) × 32 ≈ 190 bits of entropy — far beyond brute-force reach. A 16-character hex string gives 4 × 16 = 64 bits. Each additional character multiplies the possible values by the charset size, making length the most powerful factor in token security.
Common security applications: API keys — 32+ character alphanumeric strings; session tokens — 32+ character random hex or base-64 strings; password reset links — 48+ character tokens; 2FA backup codes — groups of 8–10 character codes; CSRF tokens — 32+ character tokens embedded in forms; invite/referral codes — 8–12 character alphanumeric strings; temporary file names — random names to prevent path guessing.
When humans need to read, type, or speak a code aloud — activation keys, invite codes, 2FA backup codes — ambiguous characters cause errors. The characters 0 (zero) and O (capital oh), 1 (one) and l (lowercase L) and I (capital eye) look nearly identical in many fonts. Removing them reduces the effective charset slightly — a trade-off far outweighed by usability improvement for human-facing codes.
OWASP recommends a minimum of 128 bits of entropy for security tokens. In practice: hex strings need 32 characters (128 bits), alphanumeric strings need 22 characters (≈131 bits). For API keys, 32+ characters is standard. For password reset tokens, use 48+ characters. For session tokens, PHP's default session ID is 128-bit — don't go lower.
Several commands generate cryptographically secure random strings: OpenSSL: openssl rand -base64 32 (44 base-64 chars ≈ 256 bits) or openssl rand -hex 32 (64 hex chars); Python: python3 -c "import secrets; print(secrets.token_urlsafe(32))"; Node.js: node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"; PHP CLI: php -r "echo bin2hex(random_bytes(32));". All use the OS CSPRNG.
A seeded PRNG produces a deterministic sequence from a starting seed value — given the same seed, it always produces the same output. This is useful for reproducible simulations, but catastrophic for security. If an attacker can guess or observe the seed (e.g., the current timestamp), they can predict all past and future "random" values. Always use random_bytes()/random_int() (PHP), crypto.getRandomValues() (JS), or secrets (Python) for security-sensitive randomness.
URL-safe strings use only characters that do not require percent-encoding in URLs: alphanumeric characters plus - and _. When API keys are passed as query parameters, characters like +, /, and = (common in base-64) become percent-encoded, creating mismatches if the receiver decodes inconsistently. URL-safe base-64 (RFC 4648) substitutes - for + and _ for / with no padding. JWT tokens, PKCE code verifiers, and OAuth tokens all use URL-safe encoding.

About This Random String Generator

This free random string generator creates cryptographically random strings of configurable length using any combination of uppercase letters, lowercase letters, digits, and custom characters. All generation happens server-side using PHP's CSPRNG.

When to use this tool

  • Generating API keys, secret tokens, and session identifiers
  • Creating random one-time codes and nonces
  • Producing test data with random string values
  • Generating unique file names or object keys

Related Developer Tools

Password Generator UUID Generator Hash Generator Bcrypt Generator

Related Articles

In-depth guides and technical articles.

View all →
Your Token Generator Is Biased Even With a Secure Source
Developer Oct 14, 2026
Your Token Generator Is Biased Even With a Secure Source
A token generator using a secure random source can still be biased — modulo on a 62-character set isn't uniform. Plus why 32-bit IDs collide after 77,000 values.
Why API Key Rotation Is Harder Than It Should Be — Zero-Downtime Rotation, Secure Distribution, and the Permanent Git History Problem
Developer Jul 20, 2026
Why API Key Rotation Is Harder Than It Should Be — Zero-Downtime Rotation, Secure Distribution, and the Permanent Git History Problem
API key rotation is painful because most systems treat keys as static configuration — but rotation is the primary defence against undetected compromise. Here's the five-stage key lifecycle, why email and Slack are wrong distribution channels, the zero-downtime rotation sequence (generate new key, distribute, deploy, verify, then revoke old), why a Git-committed key is permanently compromised even if deleted from the latest version, and the secret scanning bots that find committed keys within seconds of push.
Why the Same Random Token Breaks in Some Contexts — Hex vs Base64url vs Standard Base64 Explained
Developer Jun 24, 2026
Why the Same Random Token Breaks in Some Contexts — Hex vs Base64url vs Standard Base64 Explained
URL-safe Base64, hex, and standard Base64 are different representations of the same randomness — and the wrong choice causes "invalid token" errors when + and / characters in standard Base64 get interpreted as spaces and path separators in URLs. Here's a decision table for token format by context, why prefixed tokens (sk_live_, ghp_) enable security scanner detection of committed secrets, and why you should store only the SHA-256 hash of tokens, never the raw token.
Random Strings for Test Data vs Security Tokens: The Difference That's Invisible in the Output
Developer Jun 21, 2026
Random Strings for Test Data vs Security Tokens: The Difference That's Invisible in the Output
Generating a random string and generating a *secure* random string can look identical — but only one is safe as a session token or API key. Here's how CSPRNGs differ from standard PRNGs (Mersenne Twister can be fully reconstructed from 624 outputs), how alphabet choice affects entropy per character, why test data often needs structured fake data rather than random strings, and why "always use a CSPRNG" is often the simplest safe policy.
UUID v4 vs UUID v7 vs ULID vs NanoID: Which Identifier Format Should You Use?
Developer Jun 13, 2026
UUID v4 vs UUID v7 vs ULID vs NanoID: Which Identifier Format Should You Use?
UUID v4's random bits fragment database B-tree indexes, causing write amplification. UUID v7 adds a millisecond timestamp prefix to fix this. ULID is sortable and URL-safe without hyphens. NanoID is compact and customisable. Here's how each works and when to choose each format.