Generate Random Strings Online

How to Generate a Random String Online

1. Pick a Character Set: Choose Alphanumeric (A–Z, a–z, 0–9), Alpha (letters only), Numeric (digits only), Hex (0–9, a–f), Base32, Base58 (Bitcoin-style, no 0/O/I/l), Base64 (URL-safe variant available), or Custom to paste your own alphabet. Toggle uppercase, lowercase, digits, and symbols to mix and match within the alphanumeric set.
2. Set Length and Quantity: Enter the String Length (e.g., 16 for session tokens, 32 for API keys, 64 for refresh tokens) and Quantity to generate multiple strings at once — useful for seeding a coupon batch or pre-generating a pool of invite codes.
3. Exclude Ambiguous Characters (Optional): Tick this to drop the look-alikes 0, O, I, l, and 1 — recommended any time a human will read, transcribe, or dictate the string. This is the same idea behind Crockford Base32 and Base58.
4. Generate and Copy: Click Generate. Strings are produced in-browser using window.crypto.getRandomValues() — no network round-trip, no server-side log of what was generated. Copy individual strings or export the full batch as text or CSV.

Why Generate Random Strings?

A "random string" is any sequence of characters that an attacker cannot predict cheaper than brute-forcing the keyspace. The harder it is to guess, the more uses it has — from one-off shareable links to long-lived production secrets. The right format and length depend on three things: who reads the string (a human or a machine), where it travels (URL, header, QR code, printed paper), and how long it lives (one minute or one year).

• API keys and bearer tokens — A typical OAuth-style bearer token is 32+ characters from a base64-url alphabet, giving ~192 bits of entropy. Long enough that brute-force is computationally infeasible, short enough to fit in an HTTP Authorization header without wrapping.
• Session IDs and CSRF tokens — OWASP's Session Management Cheat Sheet requires a minimum of 64 bits of entropy for any session ID and recommends at least 128 bits (16 random bytes, typically 32 hex chars or ~22 base64-url chars) when you implement your own — always backed by a CSPRNG.
• Coupon and invite codes — 8–12 characters from Crockford Base32 (digits + letters minus I, L, O, U) are unique enough for millions of codes while still being typeable into a checkout form without errors.
• Database row IDs that don't leak ordering — Sequential id columns expose growth rate to scrapers. A 12–16 char random string per row keeps URLs unguessable without revealing how many records exist.
• Filenames for user uploads — Random 16-char names defeat enumeration (/uploads/IMG_0001.jpg is scrapeable; /uploads/k7Q2vR9LpNxFm3bY.jpg is not).
• Password resets, email verifications, magic links — Single-use tokens of 32+ base64-url chars with a 15-minute expiry give an attacker effectively zero brute-force window.
• Test data and fixtures — Throwaway strings for unit tests, fake user records, or load-testing payloads where you need uniqueness but not security.

Working with related identifiers? See the Password Generator for human-typeable passwords, the UUID Generator for RFC 4122 v4 IDs, or the Base64 Encoder if you have raw bytes you want to render as a string.

Character Set Comparison — Entropy per Character

Entropy (in bits) per character equals log₂(alphabet size). A longer alphabet gets you more bits per character, so the string can be shorter for the same security margin — at the cost of harder transcription.

Character Set	Alphabet Size	Bits per Char	Chars for 128 bits	Best For
Hex (0–9, a–f)	16	4.00	32	Session IDs, hashes, traditional API keys
Base32 (RFC 4648)	32	5.00	26	TOTP secrets, case-insensitive identifiers
Crockford Base32	32	5.00	26	Human-typed coupon codes (excludes I, L, O, U)
Alphanumeric (mixed-case + digits)	62	5.95	22	General-purpose tokens, slugs
Base58 (Bitcoin)	58	5.86	22	Wallet addresses, IDs read aloud (no 0/O/I/l)
Base64 / Base64-URL	64	6.00	22	API keys, bearer tokens, JWT payloads
Full ASCII printable (~94)	94	6.55	20	Maximum-density secrets stored in machines only

A 16-char alphanumeric string carries ~95 bits of entropy — comfortable for short-lived session cookies but under the 128-bit OWASP floor for long-lived tokens. Bump to 22 chars for 128 bits, or 32 chars for the 192-bit margin most production API gateways use.

Use Case → Recommended Config

Use Case	Length	Character Set	Approx. Entropy	Notes
OAuth bearer token / API key	32	Base64-url	~192 bits	Standard for Stripe, GitHub, AWS-style keys
Session ID (cookie)	32 hex / 22 base64-url	Hex or Base64	128 bits	OWASP-recommended for custom session IDs
CSRF token (per-request)	24	Base64-url	~144 bits	Short-lived, rotated each session
Password reset link token	32	Base64-url	~192 bits	Single-use, 15–60 min expiry
Coupon / promo code	8–10	Crockford Base32	40–50 bits	Look-alikes excluded; checksum char optional
Invite code (private beta)	12	Crockford Base32	~60 bits	Easy to share verbally; brute-force not the threat
Two-factor TOTP shared secret	16 (80 bits) or 32 (160 bits)	Base32	80 or 160 bits	Per RFC 6238; 160-bit recommended
Random filename / object key	16	Base64-url	~96 bits	Defeats enumeration on /uploads/ paths
Database surrogate key (public)	12	Base58	~70 bits	Like YouTube video IDs
Human-readable password	16+	Alphanumeric + symbols	~104 bits	See the Password Generator for pronounceable variants

Frequently Asked Questions

Is this generator cryptographically secure?

Yes, when generated in a modern browser. The tool calls window.crypto.getRandomValues(), which the MDN spec describes as suitable for cryptographic purposes — backed by the OS entropy source (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows). It is not Math.random(), which is a predictable PRNG explicitly flagged as unsuitable for security. The browser caps each getRandomValues call at 65,536 bytes, which the generator handles transparently for very long or bulk requests.

How do I calculate entropy for a given length and character set?

Entropy in bits = length × log₂(alphabet size). Examples: 16 hex chars = 16 × 4 = 64 bits; 22 base64 chars = 22 × 6 = 132 bits; 12 Crockford Base32 chars = 12 × 5 = 60 bits. The rule of thumb most security guides cite is 128 bits for anything long-lived (session IDs, API keys) and 80+ bits for human-typeable codes where rate-limiting also protects you.

What's the difference between Base64 and Base64-URL?

Standard Base64 (RFC 4648 §4) uses A–Z a–z 0–9 + / with = padding, which breaks URLs and filenames. Base64-URL (§5) substitutes - for +, _ for /, and typically drops the = padding. If your string will appear in a URL, query parameter, JWT segment, or filename, always pick the URL-safe variant — otherwise you'll need to manually escape +/= on every transit.

Why exclude ambiguous characters like 0, O, I, l, 1?

Anywhere a human reads, dictates, or types the string, look-alikes cause real support load. Douglas Crockford's Base32 drops I, L, O (confuse with 1, 1, 0) and U (to avoid accidental obscenity); Base58 drops 0, O, I, l. Coupon codes, recovery codes, wallet addresses, and license keys all benefit. For machine-only strings (API headers, cookies), the exclusion gains you nothing and costs ~0.07 bits per char.

Why not just use a v4 UUID?

UUIDv4 is a fine random identifier — it carries 122 bits of randomness in 16 bytes. The downsides for string-style use: it's 36 characters with four hyphens (e.g., f47ac10b-58cc-4372-a567-0e02b2c3d479), uses only hex (4 bits per char), and the version/variant bits are not random, so it's not the most entropy-dense format on the wire. For a URL token, 22 chars of base64-url carries the same ~128 bits in 39% less space. Use UUIDs when you need RFC 4122 conformance or compatibility with uuid columns in Postgres / SQL Server; use a plain random string when you just need entropy.

What's the minimum length for password-like strength?

For a string that resists offline brute force against modern GPUs, target 80 bits of entropy for medium-risk accounts and 128+ bits for high-value or long-lived credentials. With the full alphanumeric + symbols set (94 chars, 6.55 bits/char), 12 chars ≈ 79 bits and 16 chars ≈ 105 bits. NIST SP 800-63B no longer mandates symbol classes for user passwords, but the entropy math is the same: longer beats fancier every time.

Can I reproduce the same random string later?

Not from this tool — that's the point. CSPRNG output is unrecoverable by design; even the same browser tab will produce a different string on the next click. If you need a deterministic but unpredictable string (e.g., derive a token from a user ID + secret), use HMAC instead — see the Hash Generator for SHA-256 / HMAC-SHA256.

Are the generated strings logged or stored anywhere?

No. Generation runs entirely in your browser via crypto.getRandomValues(); the strings never touch any server. Closing the tab discards them. For sensitive secrets, paste them straight into your password manager or .env file and avoid sending them through chat or email.

What if I need more than 65,536 bytes in one call?

The browser's crypto.getRandomValues() rejects requests above 65,536 bytes per call with a QuotaExceededError. The generator chunks larger requests automatically — for bulk runs (say, 100,000 coupon codes), it loops in batches and concatenates, so the entropy guarantee still holds per character.