Random Key Generator

Features

• 64 to 512 bits of entropy
• Five encodings including Base58 and Base64URL
• Optional prefix for environment tagging
• Six presets for common uses
• crypto.getRandomValues, never Math.random

How to use it

1. Choose a strength, 256 bits suits almost everything.
2. Pick an encoding appropriate to where the key will live.
3. Add a prefix if you tag keys by environment.
4. Press Generate and store the result somewhere safe.

Choosing a length and an encoding

For a secret that is never transmitted in the clear and is compared server-side, 128 bits is already beyond brute force and 256 bits is the comfortable standard. Going beyond that adds length without adding meaningful security, a 512-bit key is appropriate for an HMAC signing secret, where the recommendation is to match the hash output size, but is overkill for a session token.

Encoding affects where a key can safely live. Standard Base64 uses + and /, both of which have meaning in URLs and must be escaped; Base64URL substitutes - and _ so the key can be dropped into a path or query string unmodified. Base58, which Bitcoin popularised, removes the characters people misread, 0, O, I and l: which matters if a key will ever be read aloud, written down or retyped.

The operational advice matters more than the generation. Prefixing keys by environment (sk_live_, sk_test_) prevents the expensive mistake of running test code against production. Store only a hash of the key server-side, so a database leak does not expose working credentials, this is why well-designed services show a key exactly once. And keys generated here exist only in this tab: they are not logged, stored or transmitted, so copy them before you navigate away.