🔑 API Key Generator: Secure Random Tokens and Secret Keys

What is the API Key Generator?

An API key is a string of characters that identifies and authenticates an application or user when it calls an interface. Because anyone holding the key can act with its privileges, the key needs to be unpredictable. The safest way to achieve that is to draw the characters from a cryptographically secure random source rather than from a regular pseudo-random function. In the browser that source is the Web Crypto API, specifically crypto.getRandomValues, which is exactly what this tool uses for every character it produces. Server-side equivalents are crypto.randomBytes in Node.js and secrets.token_bytes in Python.

The format you pick changes which characters appear, not how the randomness is generated. Hexadecimal uses 16 symbols (0 to 9 and a to f), so each character carries 4 bits of entropy. Alphanumeric uses 62 symbols (A to Z, a to z, 0 to 9), giving about 5.95 bits per character. Base64url uses 64 symbols (the alphanumeric set plus a hyphen and an underscore), giving a clean 6 bits per character and staying safe to drop into URLs and file names without escaping. More entropy per character means a shorter string can still be very hard to guess. All three formats start from the same random bytes; only the encoding differs.

How long should a key be? The widely cited guidance from OWASP and major API providers is at least 128 bits of entropy, with 256 bits as a comfortable default that costs nothing extra. In practice that means roughly 32 hexadecimal characters, 22 alphanumeric characters, or 22 base64url characters for the 128-bit floor, and double those lengths for 256 bits. A key built this way cannot be brute forced with any realistic amount of computing power, so length is the single most important security choice you make here.

A prefix is a short label placed in front of the random part, such as sk_live_ or tn_. Prefixes do not add security, they add clarity: they let you tell a publishable key from a secret one at a glance, route the key to the right system, and let secret scanners such as GitHub secret scanning detect a leaked credential by its recognizable pattern. This generator keeps the prefix separate from the random body so the strength of the key always comes from the random portion, never from the label.

Generating the key is only half the job. The other half is storage. A raw API key should be shown to its owner exactly once, at creation time, and never stored in plain text on your server. The standard pattern is to hash the key with SHA-256, save only the hash plus a short non-secret prefix for lookup, and compare hashes on every request. If your database is ever leaked, the stored hashes are useless to an attacker, exactly like hashed passwords. Pair this with rotation (replacing keys on a schedule such as every 90 days), per-service keys so one leak does not expose everything, and scopes that limit what each key can do.

Never build a secret from Math.random, a timestamp, an auto-increment ID, a UUID, or any value derived from user data. Those sources are predictable or insufficiently random and have led to real account-takeover incidents. The only safe input for a secret is a CSPRNG, which is precisely what this generator uses. Treat the output as sensitive from the moment it appears: copy it into a secret manager or an environment variable, keep it out of version control, and revoke and replace it the instant you suspect it has leaked.

When to use it

• Creating a secret key, bearer token, or access token for a new service, microservice, or webhook integration.
• Generating a random API key to store in a .env file or a secret manager during local development.
• Producing a batch of unique tokens at once for seeding a database, testing, or issuing to multiple clients.
• Adding a recognizable prefix so publishable and secret keys can be told apart and scanned for in code.
• Generating a strong client secret, signing key, or session token where a CSPRNG random string is required.
• Rotating an existing key by minting a fresh value of the same length and format before retiring the old one.

How to use the API Key Generator

1. Set the length, meaning how many random characters the key should contain (longer is harder to guess; 32 or more for a secret).
2. Choose a format: hexadecimal, base64url, or alphanumeric.
3. Optionally type a prefix such as sk_live_ to label the key.
4. Set how many keys you want and press Generate keys.
5. Copy one key with its own button, or use Copy all to grab the whole batch, then paste into your secret manager or .env file.

Formula & method

Worked examples

Bits of entropy by format and length (random body only, prefix excluded)

Character sets used by each format

Recommended minimum length to reach common entropy targets

Common mistakes to avoid

• Treating the prefix as part of the security. A prefix like sk_live_ is a label, not a secret. All of the strength comes from the random body, so keep the random part long enough (24 characters or more) regardless of the prefix.
• Making keys too short to save space. A very short key is faster to type but far easier to guess. For a secret key, aim for at least 128 bits of entropy, which is about 32 hex characters or 22 base64url characters.
• Committing a generated key to a public repository. Once a secret key is pushed to a public repo it is compromised, even if you delete it later. Store keys in environment variables or a secret manager and add them to your ignore file.
• Reusing one key everywhere. Sharing a single key across many services means one leak exposes all of them. Generate a separate key per service or client so you can rotate or revoke just the affected one.
• Storing the raw key in your database. Keep only a SHA-256 hash of the key plus a short prefix for lookup, and show the raw value to the owner just once. A leaked database of hashes cannot be turned back into working keys.
• Generating the secret from Math.random or a UUID. Math.random, timestamps, auto-increment IDs, and UUIDs are predictable or not random enough for secrets. Always use a CSPRNG such as crypto.getRandomValues, crypto.randomBytes, or secrets.token_bytes.

Glossary

API key

A string that identifies and authenticates an app or user when it calls an interface, granting whatever access that key is allowed.

Token

A generated credential, often used like an API key or bearer token, that proves identity or grants access without sending a password each time.

Entropy

A measure of unpredictability, in bits. More bits mean exponentially more possible values and a harder key to guess.

Base64url

A 64-symbol encoding (letters, digits, hyphen, underscore) that is safe to place in URLs and file names without escaping, unlike standard base64 which uses plus and slash.

Prefix

A short readable label placed in front of the random part of a key to identify its type or owner. It adds no security but helps secret scanners spot leaks.

CSPRNG

A cryptographically secure pseudo-random number generator, the kind of randomness suitable for secrets. The browser exposes it as crypto.getRandomValues.

Hashing

Running a key through a one-way function such as SHA-256 so you can store and verify it without keeping the raw secret. A leaked hash cannot be reversed into the key.

Key rotation

Replacing an active key with a fresh one on a schedule, such as every 90 days, so that an undetected leak has a limited useful lifetime.

Frequently asked questions