API Key Generator

Introduction:

API keys are bearer credentials. Anyone who holds a valid key can usually call the service it belongs to until the key is revoked, expires, or fails a server check. Good key generation therefore has two jobs: create enough unpredictable secret material, then keep enough readable structure around it so teams can identify, store, and rotate the key without exposing the secret again.

A useful API key format separates public routing information from the private secret. A short prefix can identify the product, an environment segment can separate live and test credentials, and a public lookup ID can help the server find the right verifier record. None of those segments should be counted as the secret. The random secret segment is the part that must resist guessing.

Readable structure is helpful only when it does not weaken the secret. A public ID can appear in logs and database indexes, but it is not proof of access. A check segment can catch a paste or typing mistake, but it is not a signature. The server still needs to compare the submitted full key with a stored verifier and enforce scope, rate limits, revocation, and audit rules.

The safest habit is to treat a newly generated key as sensitive from the moment it appears. Copy it into the intended vault or deployment system, store only the verifier hash and supporting metadata in application tables, and rotate any key that lands in chat, tickets, logs, screenshots, or shared exports.

Technical Details:

API key strength comes from uniformly random secret bytes. Encoding changes how those bytes are displayed, not how many random bits they contain. A 32-byte secret has 256 bits of secret entropy whether it is shown as Base64URL, hexadecimal, or Crockford Base32. The visible length changes because each encoding packs bits into characters differently.

The public pieces should be read as routing and operations hints. Prefix, environment, public lookup ID, separator, and check segment help people and systems sort keys, but the secret byte count is the security control that resists guessing. For fair comparisons between batches, keep the secret byte count fixed and compare the same key shape and encoding.

Formula Core:

The entropy and batch collision estimate follow simple random-byte math. The collision estimate describes accidental duplicate secrets within the requested batch, not the chance that an attacker guesses a key.

Here, B is the selected secret byte count, H is the displayed Secret entropy in bits, n is the requested Key count, and P is the approximate duplicate-secret probability for that one batch. With the default 32 secret bytes and 5 keys, the displayed entropy is 256 bits and the collision estimate is below 1e-30.

Transformation Core:

The three key shapes change which public segments appear. Prefix + public id + secret includes prefix, environment, public ID, secret, and optional check segment. Prefix + secret removes the public lookup ID but keeps the public labels. Secret only removes prefix, environment, public ID, and check segment, leaving only the encoded secret.

Everyday Use & Decision Guide:

Start with Prefix + public id + secret, Base64URL, 32 secret bytes, and a short Service prefix. That produces compact keys with 256 bits of secret entropy and a public lookup ID that can be indexed separately from the secret verifier.

Use the Environment field to prevent live, staging, test, and development keys from looking interchangeable. If the environment is sensitive or already implied by the target system, choose None. If you choose Custom, use a short alphanumeric value because punctuation is stripped before the key is assembled.

• Choose Base64URL for compact API credentials that fit URLs, headers, and CLI variables cleanly.
• Choose Hexadecimal when a system expects lowercase hex or when manual inspection matters more than length.
• Choose Crockford Base32 when humans may read or type the secret and ambiguous letters should be avoided.
• Keep Check segment on for prefixed keys that may be copied through tickets, terminals, or deployment notes.
• Use Secret only only when another system already provides naming, environment, and lookup metadata.

Read API Key Ledger first. It contains the final API key, Public id, Secret length, Secret entropy, Check, and SHA-256 storage hash. Then open Storage Review to confirm the random source, entropy, lookup ID choice, hash status, and handling warning before the batch leaves the browser session.

A key with high entropy is still unsafe if it is pasted into logs, committed to a repository, or stored as plain text in an application table. The practical handoff is to store the full key once in a vault or deployment secret store, keep the hash and public metadata on the server, and rotate anything that was exposed during setup.

Step-by-Step Guide:

Generate one rollout batch at a time so the ledger, storage review, and JSON describe the same set of credentials.

1. Set Service prefix to a short product or service code such as st, then choose Environment or enter a valid Custom environment.
2. Choose Key shape. Use Prefix + public id + secret when your server can index by public ID, or Secret only when the destination system supplies all metadata elsewhere.
3. Choose Secret encoding and Secret bytes. The summary should show the expected bit target, such as 256 bit secrets for 32 bytes.
4. Set Key count for the current rollout, then open Advanced only if you need a different Public id bytes value or Segment separator.
5. Leave Check segment included unless the destination format cannot accept it. The switch is ignored for Secret only output because there are no public segments to guard.
6. Select Regenerate keys. If the status says Web Crypto random generation is unavailable, move to a modern trusted browser. If a custom environment error appears, enter at least one letter or number or choose another environment option.
7. Review API Key Ledger and Storage Review. Confirm that Secret entropy, Random source, Server storage, and Handling match your rollout policy.
8. Copy the final keys only after the storage plan is clear. Store the full secret in the intended secret system, keep the SHA-256 storage hash for verifier storage, and rotate any key that was exposed outside the handoff path.

Interpreting Results:

The most important output is Secret entropy. It is calculated from Secret bytes and does not include prefix, environment, public ID, separator, or check segment. A default batch shows 256 bits per secret, while the smallest allowed setting shows 128 bits.

• API key is the value presented to the client. Treat it as sensitive as soon as it is generated.
• Public id can help find a verifier record, but it should not grant access by itself.
• Check catches common copy mistakes in prefixed formats. It does not replace server verification.
• SHA-256 storage hash is a verifier value for storage. It should not be used as a display copy of the secret.
• Sensitive batch in Storage Review means the current output can expose live credentials through copy buffers, downloads, screenshots, and shared notes.

Do not read a strong entropy number as a complete security review. The key still needs restricted scope, rate limits, rotation, careful storage, and removal from accidental disclosure paths. Before issuing the batch, use Storage Review to check the random source, storage hash, and handling row, then verify the receiving service will hash, compare, revoke, and audit the key correctly.

Worked Examples:

Default production-style batch

With Service prefix set to st, Environment set to Live, Key shape set to Prefix + public id + secret, Base64URL encoding, 32 secret bytes, 5 keys, and Check segment included, each ledger row follows the pattern st_live_ plus a public ID, a 43-character secret, and a 4-character check segment. Secret entropy shows 256 bits, and SHA-256 storage hash gives a verifier hash for each full key.

Secret-only hex for a constrained field

A legacy system may accept only a plain token. Choose Secret only, Hexadecimal, 16 secret bytes, and 1 key. The API key becomes a 32-character hex secret, Public id shows -, Check shows off, and Secret entropy shows 128 bits. That is the lowest entropy this generator will issue, so avoid lowering scope or rate-limit controls elsewhere to compensate for a short destination field.

Custom environment blocked by cleanup

If Environment is Custom and the custom value contains only punctuation, the normalized environment becomes empty and generation is blocked. The status asks for at least one letter or number. Enter a value such as sandbox, choose a built-in environment, or choose None before regenerating. Once the error clears, the summary returns to the bit target and key shape instead of the blocked state.

Responsible Use Note:

Generate production keys only from a trusted device and browser session. The key batch is built in the browser and the storage hashes are prepared there, but copied text, downloaded files, JSON, screenshots, browser history, and shared tickets can still leak secrets. Rotate any generated key that leaves the intended handoff path.

FAQ:

Glossary:

Bearer credential

A credential where possession of the value is usually enough to authenticate a request.

Secret entropy

The number of unpredictable bits in the random secret segment, calculated from the selected secret byte count.

Public ID

A non-secret lookup segment that helps the server find the right verifier record.

Check segment

A short non-secret value that helps catch copy or typing mistakes in prefixed keys.

Verifier hash

A stored digest used to check a submitted full key without keeping the full key in ordinary tables.

Rotation

Replacing an issued key with a new value and retiring the old one in the receiving service.

References:

• NIST Special Publication 800-63B-4, National Institute of Standards and Technology.
• FIPS 180-4 Secure Hash Standard, National Institute of Standards and Technology, August 2015.
• Crypto: getRandomValues() method, MDN Web Docs, August 19, 2025.
• Secrets Management Cheat Sheet, OWASP Cheat Sheet Series.