API Key Generator
Issue API keys the way well-run platforms do. Each key gets your prefix, so it is recognisable in logs and by secret scanners, a cryptographically random body of 128 to 256 bits, and optionally a checksum that catches typos. Next to every key the tool shows the SHA-256 hash, which is what your database should store.
- Runs in your browser
- No sign-up
- Free to use
Keys are generated in your browser and never stored or sent. Show a key to its owner once; keep only its hash in your database.
How to use API Key Generator
- Enter a prefix that identifies your product and environment.
- Choose the randomness and the character set.
- Keep the checksum on, and generate the keys.
- Give the key to its owner once and store only the SHA-256 value.
API Key Generator features
Recognisable prefix
For example myapp_live_ or myapp_test_.
128–256 bits
Random body from crypto.getRandomValues.
Checksum
CRC32 suffix that detects mistyped and fake keys before a database lookup.
Storage hash
SHA-256 of each key, for storing instead of the key itself.
Three alphabets
Base62, hexadecimal or Crockford Base32.
Never stored
Generated on your device; nothing is saved or sent.
When to use API Key Generator
- Designing the key format for a new API.
- Creating keys for a small internal service.
- Producing test keys for development environments.
- Showing a team how prefixed, checksummed keys work.
API Key Generator FAQ
Why add a prefix?
A prefix such as myapp_live_ makes keys easy to identify in logs, configuration and code reviews, and lets secret-scanning services detect leaked keys automatically. Use your own name; do not imitate another provider’s format.
What is the checksum for?
It lets your server reject mistyped or invented keys without a database query, and lets scanners distinguish real keys from random text. It adds no secrecy.
Why store a hash instead of the key?
If your database leaks, hashed keys cannot be used. Because API keys are long and random, a fast hash such as SHA-256 is sufficient; slow password hashes are not needed.
How long should an API key be?
At least 128 bits of randomness. This tool defaults to 192 bits.
Can I show the key again later?
Good practice is to show it once at creation and never again. Users who lose a key create a new one and revoke the old.
Should production keys be generated in a browser?
Production keys are best generated by your server when the user requests one. Use this tool to design the format and for testing.
Anatomy of a good API key
An API key is a long-lived secret that identifies and authorises a client. Leaked keys are among the most common causes of security incidents, so modern platforms design keys to be easy to detect, hard to guess and safe to store.
The prefix serves detection. Keys that start with a distinctive marker can be found by automated scanners in public code repositories and logs, and revoked before they are abused. A second segment for the environment, live or test, prevents test keys from being used in production and vice versa.
The random body provides the security. With 128 bits or more from a cryptographic generator, keys cannot be guessed. A short checksum at the end, calculated from the body, lets the server reject malformed keys immediately and helps scanners avoid false alarms.
Storage is the other half. Keep only a hash of each key, together with metadata such as the owner, scope and creation date. When a request arrives, hash the presented key and look up the hash. Show the full key to the user once, allow several keys per user, and make rotation and revocation easy.