API Key Best Practices: Generate, Store and Rotate

An API key is only as strong as the way it is created, stored and retired. Plenty of breaches start with a short, guessable secret or a key that sat in a public repository for months. This guide walks through the full life of a key — choosing its length and alphabet, adding a recognizable prefix, keeping it out of source control and replacing it on a schedule — so your tokens stay secret long after you generate them.

How much randomness does a key need?

The strength of a random token is measured in bits of entropy. Every character adds log2 of the alphabet size, so the same length can be weak or strong depending on the characters allowed:

• Hexadecimal (16 symbols): 4 bits per character — 32 characters give 128 bits.
• Base64 (64 symbols): 6 bits per character — 22 characters give 132 bits.
• Letters and numbers (62 symbols): about 5.95 bits per character — 32 characters give roughly 190 bits.
• Numbers only (10 symbols): about 3.3 bits per character — you would need 39 digits for 128 bits.

A common rule of thumb is to aim for at least 128 bits for anything that grants access. At that level, guessing is not a realistic attack; leaks are.

Pick an alphabet that survives the journey

Keys travel through headers, URLs, config files and terminals, so choose characters that will not be mangled on the way:

• Hex is the safest everywhere and easy to read aloud, but it is long for its strength.
• URL-safe Base64 replaces + and / with - and _, so the key can sit in a query string without percent-encoding.
• Letters and numbers are compact and copy cleanly with a double-click, because there are no punctuation marks to break the selection.

Whatever you choose, document it so client libraries can validate the format before sending a request.

How to create keys with the token generator

The tool above builds keys with the Web Crypto API right in your browser. To create a batch of production-style secrets:

1. Set the length — anything from 1 to 512 characters. For letters and numbers, 32 or more is a solid start.
2. Choose the character set: hexadecimal, letters and numbers, letters only, numbers only, Base64, URL-safe Base64, binary or a custom set you type yourself.
3. Add an optional prefix such as sk_test_ or live_ so keys are recognizable in logs and code reviews.
4. Use the letter case setting to keep mixed case or force lowercase or UPPERCASE if your system is case-insensitive.
5. Generate up to 200 tokens at once, then copy them or export as CSV, JSON or TXT.

Remember that a prefix adds no randomness — count only the random part when you estimate strength.

Store keys like passwords, not like settings

The biggest risk to a key is not brute force but exposure. A few habits close most of the gaps:

• Never commit secrets. Load them from environment variables or a secrets manager and keep .env files in your ignore list.
• Hash keys on the server. Store a SHA-256 digest of each key instead of the key itself, and show the full value to the user only once, at creation time.
• Compare in constant time so response timing does not leak how many characters matched.
• Scope every key. A read-only key for a dashboard should not be able to delete data.
• Redact in logs. Print only the prefix and the last four characters.

Rotate without breaking anything

Rotation limits the damage of a leak you have not noticed yet. The zero-downtime pattern is simple:

1. Issue a new key while the old one keeps working.
2. Deploy the new key to every client and confirm traffic is using it.
3. Revoke the old key and watch for failed requests.

Support at least two active keys per account so this overlap is possible. Rotate on a fixed schedule, immediately when someone with access leaves the team, and any time a key appears somewhere it should not — a ticket, a chat message or a screenshot.

Pro tips

• Use different prefixes for test and live keys so a test key can never be mistaken for production.
• Keep the random part at 128 bits or more and let the prefix carry the meaning.
• Record when each key was created so stale keys are easy to spot.
• Revoke first and investigate second when a key leaks.

Frequently asked questions