API Key Generator
Random API keys with the prefix convention Stripe and GitHub made standard.
Why the prefix matters
An API key is just a random secret, and the interesting design question is the part that isn't random. Stripe popularised the sk_live_ / pk_test_ convention, and GitHub followed with ghp_: a short, fixed, human-readable prefix in front of the entropy. It costs nothing and buys three things. Support can tell at a glance whether someone pasted a secret key where a publishable one belonged. Your own code can reject a test key in production before it makes a call. And — the reason it really spread — secret scanners can find your leaked key in a public repository, because a fixed prefix is something a regular expression can match. GitHub and Stripe act on those matches automatically.
How much entropy
32 bytes is the right default: 256 bits, the same strength as an AES-256 key, and utterly beyond brute force. The prefix adds none of it — it is public by design, so the entropy meter here counts only the random part. 16 bytes is still unbreakable and produces a shorter key if your users have to handle it by hand. Longer than 32 buys nothing but scroll.
Store the hash, not the key
The mistake worth avoiding is on your side, not in the generator: do not keep API keys in your database in plain text. Store a hash and compare on each request, exactly as you would for a password — then a database leak does not hand over every customer's credentials. Because the key is full-entropy random, you can hash it with plain SHA-256 rather than bcrypt or Argon2: those are slow on purpose to defend weak, human-chosen secrets, and a 256-bit random value has nothing to defend. Show the key exactly once, at creation, and make rotation a normal operation rather than an incident.
Why add a prefix at all?
It costs nothing and buys three things: support can see at a glance whether a secret key was pasted where a publishable one belonged, your code can reject a test key in production before it makes a call, and secret scanners can match a fixed prefix with a regular expression — which is how GitHub and Stripe automatically detect keys leaked in public repositories.
How should I store API keys?
Hashed, never in plain text — exactly as you would a password, so a database leak does not hand over every customer's credentials. Because these keys are full-entropy random, plain SHA-256 is enough: bcrypt and Argon2 are deliberately slow to protect weak human-chosen secrets, and a 256-bit random value has no weakness to protect. Show the key once, at creation.
How long should an API key be?
32 random bytes is the right default — 256 bits, the same strength as an AES-256 key. The prefix adds no entropy, since it is public by design. 16 bytes is still unbreakable if you need a shorter string for humans to handle.
Nothing leaves your browser
- Don't take our word for it — turn off your wifi. Every generator on this site keeps working with the network disconnected. That's the whole proof, and it takes five seconds.
- Every value comes from
crypto.getRandomValues()— the CSPRNG built into your browser, neverMath.random(). - Generated secrets are never transmitted, logged or stored: no server-side generation, no cookies, no localStorage.
- Verify it yourself in the network tab: after loading, the page only talks to our self-hosted, cookie-less analytics — which counts page views and which generator type gets copied, never any value.
- Strict Content-Security-Policy; no third-party script origins.