API Key Generator

Service prefix:

Letters and numbers only after normalization; maximum 16 characters.

Environment:

Choose the deployment lane encoded in prefixed keys.

Custom environment:

Enter at least one letter or number; maximum 16 normalized characters.

Key shape:

Use public ID plus secret for indexed verification; choose secret only for a plain random token.

Secret encoding:

Base64URL is compact, hexadecimal is familiar, and Crockford Base32 avoids ambiguous characters.

Secret bytes:

Use 32 bytes unless a destination has a documented credential-length limit.

bytes

Key count:

Generate 1-50 credentials for one controlled issuance or migration batch.

keys

Paste-check segment:

Included for prefixed shapes; secret-only output always omits it.

{{ computation.ok && computation.values.checksum_active ? 'Included' : 'Not included' }}

Settings changed. Generate a fresh batch before copying or exporting credentials.

Public ID bytes:

Use 6-8 bytes for a compact lookup ID; available only for the public-ID shape.

bytes

Segment separator:

Choose underscore, hyphen, dot, or no separator.

#	API key	Public ID	Entropy	Check	SHA-256 verifier	Copy
Generate a fresh batch to create credentials.
{{ row.index }}	{{ row.fullKey }}	{{ row.publicId \|\| '—' }}	{{ row.secretBits }} bits	{{ row.checksum }}	{{ row.sha256 }}

Area	Current state	Required handling	Copy
{{ row.area }}	{{ row.state }}	{{ row.action }}

The moment an API key is issued, possession is normally enough to make an authenticated request. That makes the random secret the security boundary. A readable prefix or environment label can help people route and detect keys, but it contributes no protection when an exposed key is accepted as a whole.

Useful key formats separate public identification from secret proof. A service prefix tells scanners and operators what kind of credential they found. An environment segment helps distinguish live and test issuance. A public ID lets a service locate the correct stored verifier without searching every credential, while the secret remains the unpredictable part presented only by the client.

Segment	Purpose	Security meaning
Prefix and environment	Human and automated identification.	Public metadata, not secret entropy.
Public ID	Indexed lookup of the corresponding verifier and policy.	May be stored and logged as an identifier.
Random secret	Proof held by the API client.	The only generated segment counted toward secret entropy.
Paste check	Detect a likely copy or transcription error.	Not a message authentication code and not a defense against tampering.

Encoding changes length and readability, not the entropy of the underlying bytes. The same 32 random bytes contain 256 bits before being written as hexadecimal, Base64URL, or Crockford Base32. Length restrictions in a receiving service should therefore be handled by choosing a compatible representation or byte count deliberately, not by trimming the generated string.

Generation is only the first step in a credential lifecycle. Each key still needs an owner, scope, expiry, secure handoff, monitoring, rotation, and revocation path. Plaintext keys should be shown only when issued and must never be placed in source control, routine logs, screenshots, or unsecured documents.

How to Use This Tool:

Choose the key shape for the receiving service before generating a controlled issuance batch.

Set a short service prefix and environment, or choose Secret only when the destination accepts an unlabelled token.
Choose Public ID + secret for indexed verification. Select an encoding and keep 32 secret bytes unless the destination has a documented credential-length rule.
Set the batch size from 1 to 50 and decide whether a four-character paste-check segment is useful.
Generate a fresh batch after any settings change, then confirm the expected entropy and key length before copying credentials.
Move each plaintext key through the approved handoff channel, store its SHA-256 verifier and metadata in the receiving service, then remove temporary copies.

Interpreting Results:

Secret entropy counts only random secret bytes. Public labels, separators, the public ID, and the paste check make the key easier to manage but do not raise that number. Estimated key characters is a compatibility measure for storage fields and headers, not a security score.

The SHA-256 value is a verifier for the full presented key. Store it with the public ID, status, scope, owner, creation time, and expiry as appropriate. A matching hash can confirm the presented bearer credential, but it cannot enforce authorization or lifecycle policy by itself.

A generated batch is sensitive immediately. If the settings-change warning appears, the prior batch has been cleared and must not be treated as matching the new composition. If any plaintext key is exposed, revoke it and issue a replacement rather than relying on the paste-check segment.

Technical Details:

Cryptographically strong random bytes are drawn in the browser and then encoded without reducing their bit content. Public segments are normalized to letters and numbers, the selected separator joins all active segments, and the complete presented key is hashed with SHA-256 for storage verification.

Formula Core:

If B is the number of random secret bytes and n is the batch size, secret entropy and the approximate probability of at least one duplicate secret in that batch are:

\begin{aligned} E & = 8 B \\ P_{duplicate} & \approx \frac{n (n - 1)}{2 \times 2^{E}} \end{aligned}

For 32 secret bytes, E is 256 bits. Encoding length is $2 B$ characters for hexadecimal, $⌈ \frac{8 B}{5} ⌉$ for Base32, and unpadded Base64URL length for Base64URL. A 32-byte Base64URL secret is 43 characters.

Transformation Core:

Stage	Mechanism	Boundary
Validate policy	Require 16 to 64 secret bytes, 1 to 50 keys, and 4 to 12 public-ID bytes.	Public-ID length matters only for the public-ID shape.
Draw bytes	Generate a fresh random byte array for every secret and, when selected, every public ID.	Generation fails if the browser’s cryptographic random source is unavailable.
Encode	Use unpadded Base64URL, hexadecimal, or Crockford Base32 for the secret; public IDs use lowercase Crockford Base32.	Encoding changes characters and length, not `E`.
Compose	Join active prefix, environment, public ID, and secret segments with the selected separator.	Secret-only output omits every public segment and the paste check.
Add paste check	Derive four Crockford Base32 characters from the composed body.	This short non-cryptographic check detects likely paste errors only.
Hash	Compute SHA-256 over the complete presented key, including public and check segments.	The generated hash is a verifier; the service must implement secure lookup, comparison, and authorization.

The estimated total length is the sum of active segment lengths plus one separator between adjacent segments. With prefix st, environment live, a 6-byte public ID, a 32-byte Base64URL secret, and a paste check, the estimate is 67 characters: 2 + 4 + 10 + 43 + 4 characters plus four underscores.

Responsible Use:

Keys are generated and hashed in the browser, but copied and downloaded credential files contain live bearer secrets. Restrict access during issuance, use a secure handoff channel, avoid ordinary email or chat, and delete temporary exports after the receiving service has stored the verifier.

The receiving service must assign least-privilege scope, enforce expiry where possible, monitor use, support rotation and immediate revocation, and avoid logging plaintext credentials. This generator does not register keys with a service or manage any part of that lifecycle.

References:

Web Cryptography Level 2, World Wide Web Consortium.
FIPS 180-4 Secure Hash Standard, National Institute of Standards and Technology.
Secrets Management Cheat Sheet, OWASP Cheat Sheet Series.