Generate an API Key — Free Prefixed Key Generator

How to Use This Secure API Key Generator

Step 1 — Select Key Length and Understand Key Length Security

Use the key length slider to choose a value between 8 to 256 characters. Length is the single biggest lever you have over entropy — every additional character multiplies the number of possible keys by the size of the alphabet used, making brute-force resistance grow exponentially. Here are the practical benchmarks:

• 16 chars — Minimum for development testing; roughly 48–96 bits of unpredictability depending on format. Acceptable for non-sensitive internal access strings.
• 32 chars — The industry-standard recommendation for live keys. A 32-character alphanumeric key yields ~190 bits of entropy — far beyond anything a modern attacker could crack.
• 40 chars — High-security tier, preferred for financial interfaces and payment processing keys where regulatory standards demand elevated strength.
• 64 chars — Maximum protection for the most sensitive systems. Suitable for signing keys and long-lived private values.
• 128+ chars — Paranoid-level protection or strict adherence to FIPS standards and NIST SP 800-90A mandates. Also useful for HMAC signing keys.

Step 2 — Choose the API Key Format

The key format controls which alphabet is used and how the raw random bytes are encoded into a printable string. Select the format that matches your platform's output requirements and URL handling constraints:

• Alphanumeric (A-Za-z0-9) — A 62-character pool that is compatible with virtually every system and uses only alphanumeric characters. The most versatile choice for general service access verification.
• Hexadecimal (0-9a-f) — A 16-symbol set producing compact binary representation. Common for HMAC signing keys and digest-based access strings where hex encoding is expected.
• Base64 (RFC 4648) — A 64-symbol set including +, /, and = padding. Most compact encoding; yields 6 bits per character. Use when space efficiency matters and the transport layer handles non-web-safe characters.
• Base64 URL-Safe — Replaces + and / with - and _, removes padding. This encoding is used by signed access strings and delegated-access bearer tokens. Safe to embed in URLs and HTTP headers.
• UUID v4 (RFC 4122) — Generates a 128-bit format identifier in the canonical xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx pattern with 122 bits of unpredictability. A compliant UUID following the RFC 4122 version 4 specification. Use this when your system expects a standard uuid string as a unique id.
• Numeric Only (0-9) — Digits-only output for verification codes and numeric-only legacy systems. Lower unpredictability per character, so use longer lengths.

Step 3 — Add a Custom Prefix (Optional)

The custom prefix input lets you prepend a human-readable label to every generated key. Prefixes are an industry pattern pioneered by payment platforms: they make it immediately obvious what type of key you're looking at and which environment it belongs to. The api_ prefix convention is widely used for general-purpose access keys. Common conventions include:

• sk_ — Private key prefix for sensitive, backend-only credentials (the sk_ prefix follows the Stripe pattern for live private keys)
• pk_ — Shareable key prefix for client-facing publishable keys
• api_ — General-purpose service access prefix
• test_ — Test environment keys to prevent accidental use in live systems
• prod_ — Live environment keys

You can also set a separator character between the prefix and the random portion. Setting a separator clearly delineates the key prefix from the random component, which aids both readability and programmatic parsing.

Step 4 — Generate and Copy Your API Keys

Once you've configured your options, click the generate button to instantly produce your key. You can set the key quantity to bulk-generate up to 25 keys at once — useful for provisioning multiple environments, seeding a staging database, or pre-generating keys for a new user cohort. Hit the one-click copy button to copy keys directly to your clipboard, or use the export buttons to download an exported key file as text, CSV, or JSON. When you export CSV or export JSON, the file contains sensitive values — delete the file after importing it into your system. If you want to export TXT, that's also available for simple line-delimited use.

API Keys vs. OAuth vs. JWT — Choosing the Right Authentication Method with This Free Online API Key Generator

API Keys — When Simplicity Wins

API keys are ideal for backend-to-backend communication, service verification, and any scenario where the calling system is trusted and fully controlled by you. They offer low configuration overhead, are stateless on the client side, and work easily with throttling and usage quotas. Attach the key in the Authorization header as an access credential or in a custom X-API-Key header, and your backend validates it on every request. Best for: REST endpoint verification, webhook signing, pipeline secrets, microservice access control, and service-to-service auth.

OAuth 2.0 — When Users Are Involved

OAuth is the right verification approach when a user needs to grant third-party access to their data without sharing their password. The client identifier and client private value are exchanged for short-lived access credentials with adjustable privilege levels and built-in expiry. OAuth 2.0 carries a higher configuration overhead but delivers superior protection for user-delegated access flows. Use it for single-page applications, mobile app connections, and any scenario involving user-delegated access rights.

JWT Tokens — For Stateless Distributed Systems

JWT tokens (JSON Web Tokens) embed claim-based access rights directly into the payload, enabling stateless verification across distributed systems and microservices. Because the backend validates the signature rather than looking up the credential in a database, signed JSON tokens are excellent for microservice access control and cloud-native architectures. The tradeoff: revocation is harder without a blocklist. This format uses base64 encoding for its header and payload components, making it web-safe by design.

REST vs. GraphQL Authentication Considerations

For REST endpoints, access keys map naturally to resource-level control: one key per privilege tier. For query-based interfaces, you often need fine-grained access rights at the query level — controlling who can execute which queries (users:read, users:write, admin:settings, payments:process, analytics:export, webhooks:create). Both REST and query-based interfaces support key-based access via request headers, but the flexibility of query languages makes delegated-access flows with custom privilege layers or dedicated access-control handlers a more scalable choice for complex scenarios.

Code Examples: Programmatic API Key Generation

Node.js and JavaScript — crypto.randomBytes()

The Node.js crypto module's crypto.randomBytes function is the correct tool for programmatic key generation in JavaScript environments. It calls the operating system CSPRNG directly — on Unix-based systems this is /dev/urandom; on Windows it is BCryptGenRandom. Never use Math.random() or Math.floor() for security-sensitive strings; these are standard pseudorandom generators with no cryptographic guarantee. The generateUUID pattern that uses timestamp-based seeding is similarly unsafe for production use in any devops pipeline or live environment.

const crypto = require('crypto');

// Generate a cryptographically secure 32-character base64url key
// with a sk_live_ prefix following the Stripe pattern
function generateApiKey(prefix = 'sk_live_', byteLength = 24) {
  const randomPart = crypto.randomBytes(byteLength).toString('base64url');
  return `${prefix}${randomPart}`;
}

const apiKey = generateApiKey();
console.log(apiKey);
// Output: sk_live_8vR2xKmL3wN9QaBcDeFgHiJk

// For key pairs:
const publicKey  = generateApiKey('pk_live_', 16); // shareable frontend identifier
const secretKey  = generateApiKey('sk_live_', 32); // private value — never expose
console.log({ publicKey, secretKey });

Generate an API Key in the Terminal (Linux and macOS)

For local key generation without opening a browser, use your terminal directly. The openssl rand command draws from the operating system's entropy pool and is available on every Unix-based system. The one-liner below is equally portable and produces a base64 encoded key with a prefix in a single command. These terminal approaches are useful in a devops workflow where scripting and automation are preferred:

node -e "console.log('sk_live_' + require('crypto').randomBytes(24).toString('base64url'))"

echo "api_$(openssl rand -base64 32 | tr -dc 'a-zA-Z0-9' | head -c 32)"

python3 -c "import secrets; print(f'sk_live_{secrets.token_urlsafe(24)}')"

The Python secrets module (token_urlsafe) is the recommended tool in Python 3.6+. It uses secure random byte generation internally via os.urandom. In Java and Kotlin, use SecureRandom for cryptographically strong values. In Go, use crypto/rand. In Ruby, use SecureRandom. In C#, use RandomNumberGenerator for ASP.NET Core Web interfaces. In C++, use random_device for game engines and native applications. In PHP, use random_bytes() with base64 encoding. Every language has a CSPRNG — the key is always to use the cryptographic module, never the standard math library.

Access Control Handler — Validating API Keys

Generating a key is only half the story. Here is a minimal but production-ready access control handler implementation that validates incoming keys, checks privilege levels, and enforces access controls — demonstrating how key-based verification plugs into a real backend. This pattern is fundamental to web security in any service-oriented architecture, and an important part of any security audit checklist for production deployments:

const crypto = require('crypto');

// In production: load from a database or secrets vault, not a hardcoded Map
const API_KEYS = new Map([
  ['sk_live_8vR2xKmL3wN9QaBcDeFgHiJk', {
    permissions: ['users:read', 'payments:process'],
    rate_limit: '1000/hour',
    api_version: 'v2',
    scopes: ['read', 'write']
  }]
]);

function requirePermission(requiredPermission) {
  return (req, res, next) => {
    // Extract access credential from Authorization header
    const authHeader = req.headers['authorization'] || '';
    const apiKey = authHeader.startsWith('Bearer ')
      ? authHeader.slice(7)
      : req.headers['x-api-key'];

    if (!apiKey) {
      return res.status(401).json({ error: 'API key required' });
    }

    const keyData = API_KEYS.get(apiKey);
    if (!keyData) {
      return res.status(401).json({ error: 'Invalid API key' });
    }

    const hasPermission =
      keyData.permissions.includes('*:*') ||
      keyData.permissions.includes(requiredPermission);

    if (!hasPermission) {
      return res.status(403).json({
        error: 'Insufficient permissions',
        required: requiredPermission,
        granted: keyData.permissions
      });
    }

    req.apiKeyData = keyData;
    next();
  };
}

// Route usage
app.get('/users',  requirePermission('users:read'),      (req, res) => res.json({ users: [] }));
app.post('/users', requirePermission('users:write'),     (req, res) => res.json({ created: true }));
app.post('/pay',   requirePermission('payments:process'),(req, res) => res.json({ charged: true }));

Cryptographic Security Standards Behind This Generator

The entropy calculation for any generated key follows a straightforward formula rooted in cryptography. For an alphanumeric key drawn from a 62-character pool using secure random selection:

For a 32-character alphanumeric key:

For a hexadecimal key of the same length:

At 190 bits, a 32-character alphanumeric key is computationally infeasible to crack by brute force: even at a trillion guesses per second, you would need more attempts than there are atoms in the observable universe. This generator meets NIST SP 800-90A and FIPS standards regulatory requirements through its use of the browser's built-in cryptographic interface and a validated entropy source. The underlying generator is seeded by hardware-level OS events, not software state, and passes NIST randomness test validation for statistical quality.

Entropy, Randomness, and the Math Behind a Cryptographically Secure API Key

Why CSPRNG Beats Math.random() for API Key Generation

A secure random number generator differs from a standard pseudorandom number generator in one critical way: its output is computationally indistinguishable from true randomness, even to an adversary who knows the algorithm. Math.random(), timestamp-based seeds, and performance.now() — as seen in some CodePen generateUUID implementations — all derive their state from predictable inputs. A UUID generated with Math.floor(d + Math.random() * 16) and a timestamp seed fails NIST statistical tests and is vulnerable to timing attacks. By contrast, the browser's cryptography interface and Node.js's crypto.randomBytes tap directly into the operating system CSPRNG, which combines hardware randomness, interrupt timing, and system-level unpredictability into a pool that passes NIST SP 800-90A standards.

The practical consequence: at 40 characters of alphanumeric output, you have ~238 bits of unpredictability. The number of possible keys is \(62^{40} \approx 8.39 \times 10^{71}\) — far beyond guessing reach. Even exhaustive attacks at a trillion attempts per second would need vastly longer than the age of the universe. That is maximum entropy by any industry definition.

Client-Side Generation and the Privacy Guarantee

This tool operates entirely through client-side generation — your browser computes every key locally using the principles of cryptography. There are no external calls, no backend logs, and no remote key storage on any system. The keys never leave your device and remain completely private. This design is intentional: it eliminates the risk of a supply-chain attack or a backend breach exposing your freshly generated access values. The exposure risk is zero because there is no backend. This is also why the tool is genuinely free — there is no backend infrastructure to run.