API Key Generator
Free API key generator — prefixed, high-entropy keys with an optional checksum so typos fail before a database lookup, plus a well-formedness checker. Generated locally in WebAssembly; nothing is uploaded.
Verify a key
Checks the prefix and the checksum. It cannot tell you whether a key is valid — only whether it is well-formed.
Runs entirely in your browser — nothing you enter is uploaded or stored.
Issuing API keys
An API key is a bearer token: whoever holds it is the account. That makes the interesting design questions operational rather than cryptographic — how you recognise one, how you revoke one, and what happens when one ends up in a public repository.
Anatomy
A well-formed key has three parts. A prefix naming the system and environment, so it is greppable and so secret scanners can match it. A random body carrying the actual entropy. An optional checksum, so a typo is rejected by arithmetic instead of a database round-trip. Only the middle part is security; the other two are operations, and they are what makes a leaked key recoverable.
Store the hash, not the key
Treat an API key exactly like a password on your side: hash it, store the hash, compare on each request. Providers show a key once at creation because they cannot show it again — they no longer have it. That is the correct design, and it is why "I lost my key" is answered with "here is a new one" rather than "here it is again".
Frequently asked questions
Why put a prefix on an API key?
So that a leaked key can be recognised on sight. GitHub scans public repositories for strings starting ghp_, and Stripe for sk_live_, and revokes them automatically. A prefix costs nothing and turns a key from an anonymous blob into something a secret scanner can find before an attacker does. It also tells your own logs which system a key belongs to.
What is the checksum for?
It lets your API reject a typo without a database lookup. The last few characters are derived from the rest, so a mistyped or truncated key fails arithmetic before it reaches storage. It is not a security feature — anyone can compute it — it is a way to answer "this is malformed" instantly and keep the expensive lookup for keys that could plausibly be real.
How many bytes of randomness do I need?
32 bytes (256 bits) is the sensible default and what most providers issue. 16 bytes is already beyond brute force; more than 32 buys nothing and makes the key unwieldy. The number that matters is entropy, not string length — a long key over a small alphabet can be weaker than a short one over a large alphabet.
How should I store the key on my side?
Hash it, the same way you would a password. Store a hash and compare on each request, so a database leak does not hand over working credentials. Show the key to the user exactly once at creation — every provider that does this is doing it for that reason, not to be awkward.