API Key Generator

Generate secure API keys for authentication and authorization in your applications.

Security Tip: Store API keys securely and never expose them in client-side code. Use environment variables for server-side applications.

How the API Key Generator Works

This API key generator uses the browser's built-in Web Crypto API (crypto.getRandomValues) to produce cryptographically secure random keys. Every key is generated entirely in your browser — no data is sent to any server — making it safe to use for real production credentials.

When you click Generate API Key, the tool fills a Uint32Array of the requested length with cryptographically random 32-bit integers. Each integer is then reduced modulo the charset size to select a character, and those characters are joined after the optional prefix. This technique ensures uniform distribution across the character set.

You control four parameters:

  • Prefix — A short human-readable label prepended to every key (e.g. sk_, api_, tok_). The prefix does not count toward the random character length.
  • Length — The number of random characters appended after the prefix (16 to 64). This is the primary driver of cryptographic strength.
  • Character Format — Determines which characters appear in the random segment. Larger alphabets produce more entropy per character.
  • Quantity — Generate up to 10 unique keys in one click, useful for bulk provisioning of API clients or test environments.

Generated keys are ready to copy individually. Use them as Bearer tokens, webhook secrets, SDK credentials, or any other authentication mechanism your application requires.

Entropy Calculation

entropy (bits) = length × log₂(charset_size)

Where:

  • entropy= Cryptographic strength of the key in bits
  • length= Number of random characters generated (slider value, 16–64)
  • log₂= Base-2 logarithm
  • charset_size= Number of distinct characters in the chosen format: alphanumeric = 62, lowercase = 36, hex = 16, base64url = 64

Understanding Character Formats

Choosing the right character format is a balance between entropy density, system compatibility, and readability. This API key generator offers four formats, each suited to different integration contexts.

Format Charset Size Bits per char Best for
Alphanumeric A–Z, a–z, 0–9 62 5.95 General-purpose API tokens; widest compatibility
Lowercase a–z, 0–9 36 5.17 Case-insensitive systems, slugs, URLs
Hexadecimal 0–9, a–f 16 4.00 Database UUIDs, checksums, OAuth secrets
Base64 URL A–Z, a–z, 0–9, -, _ 64 6.00 JWT payloads, URL parameters, cookie values

Hex keys are the most portable across all languages and systems but require a longer key length to achieve the same entropy as alphanumeric or base64url keys. Base64 URL format achieves the highest bits-per-character of all four options and is safe to embed directly in query strings without percent-encoding.

Key Entropy and Security Strength

Entropy measures how unpredictable a key is. A key with 128 bits of entropy is considered computationally infeasible to brute-force with current hardware and algorithms. NIST SP 800-132 and similar guidance recommend at least 128 bits for shared secrets used in authentication.

To reach 128 bits of entropy with each format, you need a minimum random-character length of:

  • Alphanumeric (62 chars): ⌈128 ÷ 5.954⌉ = 22 characters
  • Lowercase (36 chars): ⌈128 ÷ 5.170⌉ = 25 characters
  • Hex (16 chars): ⌈128 ÷ 4⌉ = 32 characters
  • Base64 URL (64 chars): ⌈128 ÷ 6⌉ = 22 characters

The default length of 32 characters far exceeds the 128-bit threshold for every format. At length 32 with alphanumeric encoding, entropy reaches approximately 190.5 bits — strong enough for even the most sensitive production APIs. For extremely high-value secrets such as master signing keys or root credentials, push the slider to 64 characters to achieve 256–384 bits of entropy.

Remember: entropy only measures how hard the key is to guess by brute force. Proper secret management — storing keys in environment variables, rotating them regularly, and revoking compromised keys immediately — is equally important for real-world security.

API Key Prefix Conventions

A well-chosen prefix makes key type immediately recognizable in logs, error messages, and code reviews without revealing the secret itself. Many popular API providers have standardized on short prefix conventions:

  • sk_ — Secret key (server-side only; never expose in client code)
  • pk_ — Public key (safe for browser/mobile clients)
  • api_ — Generic API credential for third-party integrations
  • tok_ — Short-lived or scoped access token
  • live_ — Production environment key (distinct from test keys)
  • test_ — Sandbox or test environment credential (safe to share within a team)

Beyond readability, prefixes allow automated secret-scanning tools (such as GitHub Secret Scanning or truffleHog) to detect accidentally committed credentials by registering the known prefix pattern. This is why Stripe, Twilio, and GitHub all use distinctive prefixes for their API keys.

You can also type a completely custom prefix — for example, myapp_v2_ — to embed your service name and version in every key. The prefix is prepended verbatim and does not affect the randomness or entropy of the generated secret portion.

API Key Security Best Practices

Generating a cryptographically strong key is only the first step. How you store, transmit, and revoke keys determines your actual security posture. Follow these best practices to keep your API keys safe throughout their lifecycle.

Storage

Never hardcode API keys directly in source code. Use environment variables (.env files excluded from version control) or a dedicated secrets manager such as AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. In containerized environments, inject secrets at runtime via orchestration platform secrets (e.g., Kubernetes Secrets).

Transmission

Always transmit API keys over HTTPS/TLS. Pass them in request headers (e.g., Authorization: Bearer <key>) rather than in URLs, since URLs appear in server logs, browser history, and referrer headers.

Scope and Rotation

Issue keys with the minimum permissions required for the task (principle of least privilege). Rotate keys regularly — at least every 90 days for long-lived credentials. Generate a fresh replacement key and verify it works before revoking the old one to avoid service interruptions.

Revocation

Immediately revoke any key that may have been exposed. Store a hash (e.g., SHA-256) of each issued key in your database rather than the plaintext key itself, and compare hashes on each request. This limits the damage if your database is ever compromised.

Worked Examples

Default Secret Key (Alphanumeric, 32 chars)

Problem:

Generate a production secret key with the default settings: prefix 'sk_', length 32, alphanumeric format.

Solution Steps:

  1. 1Charset: alphanumeric — A–Z, a–z, 0–9 — 62 distinct characters.
  2. 2Random segment length: 32 characters (slider default).
  3. 3Entropy = 32 × log₂(62) = 32 × 5.954 ≈ 190.5 bits — well above the 128-bit minimum.
  4. 4Total key length: prefix 'sk_' (3 chars) + 32 random chars = 35 characters.
  5. 5Example output: sk_Xk9mR3qTvL7wNpJ2cBsYeA8dFhZuG0i

Result:

A 35-character key with ~190.5 bits of entropy — suitable for any production API authentication scenario.

Hex Token (No Prefix, 32 chars)

Problem:

Generate a hex-format secret suitable for an OAuth client secret, with no prefix and length 32.

Solution Steps:

  1. 1Charset: hexadecimal — 0–9, a–f — 16 distinct characters.
  2. 2Random segment length: 32 characters.
  3. 3Entropy = 32 × log₂(16) = 32 × 4 = 128 bits — meets the NIST minimum for shared secrets.
  4. 4No prefix is added; the final key is exactly 32 hex characters long.
  5. 5Example output: 3f8a1c09d4e72b560afd3891c7e20b45

Result:

A 32-character hex key with exactly 128 bits of entropy — compact and universally portable across all languages and systems.

High-Security Base64 URL Key (64 chars, api_ prefix)

Problem:

Generate a maximum-strength API key using base64url format, length 64, and prefix 'api_' for a high-value service.

Solution Steps:

  1. 1Charset: base64url — A–Z, a–z, 0–9, -, _ — 64 distinct characters.
  2. 2Random segment length: 64 characters (slider maximum).
  3. 3Entropy = 64 × log₂(64) = 64 × 6 = 384 bits — extremely high security margin.
  4. 4Total key length: prefix 'api_' (4 chars) + 64 random chars = 68 characters.
  5. 5Example output: api_Xk9mR3qTvL7wNpJ2cBsYeA8dFhZuG0iMnQr5oPsWtYlUvEbDfCgHjKxIz4a-_

Result:

A 68-character key with 384 bits of entropy — appropriate for root credentials, signing keys, or multi-tenant platform master secrets.

Lowercase Alphanumeric Batch (5 Keys, test_ prefix)

Problem:

Provision 5 test API keys using lowercase alphanumeric format, length 32, and prefix 'test_'.

Solution Steps:

  1. 1Charset: lowercase alphanumeric — a–z, 0–9 — 36 distinct characters.
  2. 2Random segment length: 32 characters; quantity = 5.
  3. 3Entropy per key = 32 × log₂(36) = 32 × 5.170 ≈ 165.4 bits each.
  4. 4Total key length per key: prefix 'test_' (5 chars) + 32 chars = 37 characters.
  5. 5The generator calls crypto.getRandomValues independently for each of the 5 keys, so all keys are statistically independent.

Result:

Five unique 37-character test keys, each with ~165.4 bits of entropy, ready for distribution to test clients or CI/CD pipelines.

Tips & Best Practices

  • Use the 'sk_' prefix for server-side secret keys and 'pk_' for public keys to make the distinction visible at a glance in code reviews.
  • Set length to at least 32 characters for any production key — this gives 128–192 bits of entropy across all formats.
  • Store generated keys in a password manager or secrets manager (e.g., 1Password, AWS Secrets Manager) immediately after copying, before closing the tab.
  • Never paste API keys directly into Slack, email, or issue trackers — use a secrets manager or an encrypted channel instead.
  • Use the 'test_' prefix for sandbox credentials so engineers immediately know a key is safe for non-production use.
  • Rotate long-lived API keys at least every 90 days, and immediately after any team member with key access leaves the organization.
  • Enable GitHub Secret Scanning or a similar tool in your repository — it can auto-detect and alert on accidentally committed API keys.
  • Generate one key per service or integration rather than sharing a single key across multiple consumers, so you can revoke individual access without disrupting all clients.

Frequently Asked Questions

Yes. The generator exclusively uses <code>crypto.getRandomValues</code>, which is the Web Crypto API's cryptographically secure pseudorandom number generator (CSPRNG). It is seeded by the operating system's entropy pool (e.g., /dev/urandom on Linux) and is considered cryptographically secure for production credentials. No keys are stored, logged, or transmitted — generation happens entirely in your browser.
Alphanumeric uses 62 characters (A–Z, a–z, 0–9) while base64url uses 64 characters (the same 62 plus hyphen and underscore). Base64url produces slightly more entropy per character (6.00 bits vs 5.95 bits) and is specifically designed to be safe in URLs and HTTP headers without percent-encoding. If you plan to embed the key in a query string or cookie, base64url is the better choice.
NIST and industry consensus recommend at least 128 bits of entropy for shared secrets. With the default alphanumeric format, a length of 22 characters is the theoretical minimum to reach 128 bits, but 32 characters (the default) gives you ~190 bits — a comfortable security margin. For master or signing keys that protect multi-tenant systems, use the maximum length of 64 characters to achieve 256–384 bits of entropy.
No. The prefix is a fixed, publicly known string (e.g., 'sk_') that appears at the start of every key. It helps with identification and automated secret scanning but adds no randomness. All cryptographic strength comes from the random segment specified by the Length slider. An attacker who knows the prefix still has the full entropy of the random portion to brute-force.
Hex is universally portable and trivial to parse in any programming language, making it ideal for database UUIDs, HMAC secrets, and legacy systems that only accept lowercase alphanumerics. However, a hex key must be 32 characters long to match the entropy of a 22-character alphanumeric key, so you trade key length for compatibility. If key length is not a constraint, alphanumeric or base64url are more efficient choices.
Yes — use the Quantity slider to generate between 1 and 10 keys in a single click. Each key is generated independently using a fresh call to <code>crypto.getRandomValues</code>, so there is no statistical correlation between keys in the same batch. This is useful for bulk-provisioning API clients, seeding a test environment, or rotating a set of microservice credentials simultaneously.
Revoke the compromised key immediately in your API management console or backend. Generate a fresh key using this tool, update all services and environment variables that used the old key, and audit access logs for any unauthorized activity that occurred during the exposure window. If the key granted write or delete access, consider rolling back any changes made while it was compromised.

Sources & References

Last updated: 2026-06-05

💡

Help us improve!

How would you rate the API Key Generator?

<>

Editorial Note

MyCalcBuddy Editorial Team

This page is maintained as an educational calculator reference.

Source

Formula Source: Standard Mathematical References

by Various

UpdatedLast reviewed: May 2026
CheckedFormula checks are based on standard references and internal QA review.