API Key Generator

How to use API Key Generator

1. Choose a format — hex is the safe default, base58 for a shorter string.
2. Set the length; 32 hex characters is 128 bits, 64 is 256.
3. Generate and copy the key straight into your secrets store.
4. Store a hash of it server-side, never the key itself.
5. Generated with crypto.getRandomValues, so suitable for production use.
6. Base58 omits 0, O, I and l, which makes keys safer to read aloud and retype.
7. The key exists only in this tab — copy it before navigating away.

How long a key needs to be

128 bits of randomness is the practical floor and 256 bits is comfortable. In hex that is 32 and 64 characters; base58 packs the same entropy into fewer characters, which is why cryptocurrency addresses use it. What matters is the entropy, not the length of the string — a 64-character key built from a predictable pattern is worth nothing, while 32 random hex characters is beyond any brute force.

Prefix your keys, and make them recognisable

Stripe’s sk_live_ and pk_test_ convention has been widely copied because it solves real problems: a developer can tell a secret key from a publishable one at a glance, a live key from a test key, and — crucially — automated secret scanners can recognise the pattern and alert when one is committed to a public repository. GitHub’s secret scanning partners with providers on exactly these prefixes. A bare random string has none of that.

Store a hash, not the key

Treat API keys like passwords: store a hash in your database and show the key to the user exactly once, at creation. If your database leaks, hashed keys are useless to the attacker. Because keys are high-entropy random strings rather than human-chosen passwords, a fast hash such as SHA-256 is adequate here — the dictionary attacks that make bcrypt necessary for passwords do not apply. Store a prefix and a last-four in plaintext so users can identify which key is which.

Rotation, scoping and expiry

Issue keys that can be revoked individually rather than one shared secret, so a compromise is contained and rotation does not break everything at once. Scope them to the minimum permissions needed — a read-only key for a reporting integration cannot be used to delete anything. Set expiry dates, log last-used timestamps so you can spot keys that are no longer needed, and allow two active keys during a rotation so customers can migrate without downtime.