API Key Generator

Real-world use cases

• Mint a live secret key for a new service or integration

  You are wiring up a webhook receiver and need a bearer token your callers will send in the Authorization header. Pick the sk_live_ prefix, base62 charset, length 32 (about 190 bits), generate one, and the strength panel confirms it is far past any brute-force threat. Copy it once, store the hash on your side, and hand the plaintext to the client exactly once. Because generation is local, the only copy that ever existed off your machine is the one you deliberately send.

• Issue separate keys for live and test environments

  Stripe-style prefixes exist so a leaked key tells you instantly which environment it belongs to. Generate a batch with sk_live_ for production and a second batch with sk_test_ for staging, then seed each environment's secret store. When a key shows up in a log or a GitHub push, the prefix tells your scanner whether to rotate the real money path or just a sandbox token. Set count to the number of tenants you are provisioning and download the whole batch as a .txt.

• Rotate a compromised key without downtime

  A key leaked into a public repo. Generate a replacement with the same prefix and length so it slots into your existing validation regex, add it alongside the old one, deploy, then revoke the old key once traffic has moved over. Keeping the random body length identical means your column width, rate limiter keying, and log redaction rules all keep working with no schema change.

• Generate base64url tokens that survive being put in a URL

  Some flows put the token in a query string or path segment, where + and / from standard base64 would need percent-encoding. Switch the charset to base64url, which uses - and _ instead, so the key drops into a magic-link or password-reset URL untouched. Length 43 gives you 256 bits, matching a SHA-256 worth of entropy in a single copy-paste-safe string.

• Stub realistic-looking keys for docs, demos, and tests

  Your API reference needs example keys that look real but are not. Generate a handful with your real prefix, paste them into the docs and into snapshot-test fixtures, and they read as authentic without ever being valid against your auth server. Use a fixed batch so the docs and the tests reference the same throwaway strings instead of churning on every rebuild.

Common pitfalls

• Generating keys with Math.random() in a quick script. Math.random() is a non-cryptographic PRNG: its state can be recovered from a few outputs, so an attacker who sees one key can predict the next. This tool uses crypto.getRandomValues exclusively. If you build your own generator, the byte source must be the Web Crypto API or a server-side CSPRNG, never the plain Math.random().

• Trusting the prefix to add security. A prefix like sk_live_ is routing and scanning metadata, not a secret: it is predictable and contributes zero entropy. The strength panel here counts only the random body for exactly this reason. A 4-character random body behind a long fancy prefix is still trivially brute-forced, so size the body, not the label.

• Storing the raw key in your database. Treat an API key like a password: keep only a salted hash (or an HMAC) and compare hashes on each request. If your database leaks and you stored plaintext keys, every one is immediately usable. Show the full key to the user exactly once at creation, then keep just the hash and a prefix for display.

Privacy