Random String Generator

Random String Generator: Tokens, Keys, and IDs on Demand

You need a random string. Maybe it's an API key, a session token, a CSRF nonce, or a unique filename for S3. You don't want a UUID — you want control over the length, the characters, and the format.

This tool generates cryptographically random strings using your browser's crypto.getRandomValues() API. Same source of randomness as TLS key generation. Not Math.random(). The output looks like k7mQ9vXp2dLfR3nT — and it's genuinely unpredictable.

No signup, no install — just paste and go.

What's actually happening

The tool picks characters from your chosen character set using the Web Crypto API's random number generator. Each position is independently random — no pattern, no seed to guess, no sequence to predict.

The randomness quality matters. Math.random() is a PRNG — given the same seed, it produces the same sequence. An attacker who knows the algorithm and enough outputs can predict future values. crypto.getRandomValues() pulls from your OS entropy pool (hardware interrupts, timing jitter) and is computationally indistinguishable from true randomness.

Using it

Set your length. Pick a character set (alphanumeric, hex, or custom). Hit Generate. Hit Copy. Generate more if you need a batch.

When you'd actually reach for this

• API keys for a SaaS product — 32–48 character base62 strings for customer-facing auth
• OAuth state parameters — the spec requires an unpredictable random string to prevent CSRF
• Unique S3 object keys — random prefixes avoid hot partitions and guarantee no collisions
• Test database seed data — realistic-looking IDs and tokens for dev environments
• CSRF tokens — generate server-side, embed in forms, validate on submission
• Short URL slugs — 8-character base62 gives you 218 trillion combinations

Why not just use a UUID?

UUIDs are great, but they're inflexible. Fixed format. Fixed length (36 characters). Fixed character set (hex + hyphens). You can't make a UUID shorter or change the alphabet.

Random strings give you exactly what you need. A 12-character base62 token for a short URL. A 64-character hex string for a signing key. A 21-character nanoid for a document ID.

Use UUIDs when interoperability matters — databases, APIs, and frameworks all have native UUID support. Use random strings when you need a custom format.

Token formats and how long to make them

Hex (0-9a-f) — 4 bits of entropy per character. Common for checksums and hashes. 32 hex characters = 128 bits of entropy: a3f8b2c1d4e5f67890abcdef12345678.

Base62 (0-9A-Za-z) — 5.95 bits per character. URL-safe, no escaping issues. The practical default for API keys: k7mQ9vXp2dLfR3nT.

Base64URL (0-9A-Za-z-_) — 6 bits per character. Matches JWT encoding. Slightly more dense than base62.

Nanoid format (A-Za-z0-9_-, 21 chars) — 126 bits of entropy. Compact, URL-safe, widely adopted: V1StGXR8_Z5jdHi6B-myT.

How long should they be? Depends on what you're protecting:

• Session tokens: 32–64 characters (128–256 bits)
• API keys: 32–48 characters
• CSRF tokens: 32 characters
• Short URL slugs: 8–12 characters

General rule: aim for at least 128 bits of entropy for anything security-sensitive. With base62, that's ~22 characters. With hex, 32.

Troubleshooting

My token was rejected by the API — check allowed characters. Some systems reject special characters, or expect specific formats (hex only, alphanumeric only). Regenerate with the right character set.

I need to use this in a shell script — avoid special characters that need escaping ($, !, ', \, spaces). Stick to base62 or hex.

Is this safe for production secrets? — the randomness is cryptographically secure, yes. But you generated it in a browser tab. Transfer it securely (not Slack, not email) and store it in a secrets manager. Don't commit it to git.

Math.random() is fine for my use case, right? — if it's test data, shuffling, or anything where predictability doesn't matter, sure. For API keys, tokens, or anything security-adjacent, absolutely not.

How do I calculate the entropy of my string? — length × log2(charset_size). Base62, 32 chars = 32 × 5.95 ≈ 190 bits. More than enough.

What to do with it

Paste it wherever you need it — environment variables, secrets managers, API dashboards, config files.

For production, generate tokens in your application code, not a web tool. Node has crypto.randomBytes(). Python has secrets.token_urlsafe(). Go has crypto/rand. This tool is for quick generation and testing.

One last thing: always prefix your API keys or tokens with a short identifier. Stripe does sk_live_, GitHub does ghp_. It makes leaked tokens instantly identifiable in log scanning tools and secret detection (like trufflehog or GitHub's push protection). It costs you nothing and saves headaches when something leaks.