Skip to main content
June 4, 2026 · numbers · 4 min read

API Key Generator Guide — Formats, Prefixes, and Where Random Keys Belong

How API key formats work — hex, alphanumeric, prefixed, segmented — when generated keys are appropriate, and how to handle real keys safely.

Last updated June 4, 2026 · 4 min read

Every integration tutorial, mock server, and seeded database needs API keys that look real without being real. The API Key Generator produces them in the four formats running through modern APIs — 64-character hex, 32-character alphanumeric, Stripe-style prefixed keys, and segmented human-readable tokens — entirely in your browser, with nothing logged or sent anywhere.

The four formats and what they're for

Format is a real engineering decision, not cosmetics:

  • Hex (64 chars) maps cleanly onto the 256-bit shape used for HMAC signing and webhook secrets. If a key feeds a signature scheme, hex is the convention.
  • Alphanumeric (32 chars) packs ~190 bits into a shorter, copy-friendly string. The default choice when humans paste keys between dashboards.
  • Prefixed (sk_live_...) encodes scope and environment into the token itself. Stripe popularized it; most SaaS APIs have adopted some variant.
  • Segmented (xxxx-xxxx-xxxx-xxxx) trades a few bits for readability — the format for keys that get read over the phone or typed from paper.

Set a custom prefix (myapp_prod_, api_v2_) to match your own API's convention, and generate several keys per click for fixtures and docs.

Why prefixes prevent real incidents

The sk_live_ pattern earns its ubiquity: a key's blast radius is visible from its first characters. Humans reviewing a config file spot a production secret instantly; secret-scanning tools flag sk_live_ tokens in public commits within seconds of a push. If you operate your own API, adopting the same pattern — distinct prefixes for production, test, and publishable keys — is one of the cheapest security wins available. It also makes documentation safer: example keys with a _test_ or obviously fake prefix can't be mistaken for credentials.

Where generated keys belong — and where they don't

Use generated keys for development, testing, documentation, and seed data: realistic fixtures for an integration test, placeholder values in a .env.example, believable keys in API docs and screenshots. They have the right shape, length, and character set, so format validation passes and examples read true.

Don't use them as production secrets. This tool draws from the browser's standard Math.random, which is fast and fine for placeholders but not a cryptographically secure source. Production keys should come from a CSPRNG on the server — crypto.randomBytes(32) in Node, secrets.token_hex(32) in Python — or from your API gateway's issuing flow. Store only a hash of issued keys, exactly as you would passwords, and rotate on any suspicion of exposure.

Handling real keys without incidents

The habits that keep keys out of postmortems: keep secrets in environment variables or a secrets manager, never in code; commit a .env.example with generated placeholder keys so the real .env never needs to be shared; scope each key to the minimum permissions its client needs; and issue separate keys per integration so revocation doesn't break everything at once.

Frequently asked questions

What is an API key?

A token a client sends with each request so the server knows who's calling and what they're allowed to do. It identifies an application rather than a person, and is designed to be issued, rotated, and revoked per client.

Are these generated keys safe for production?

No — they're for development, testing, and documentation. The generator uses Math.random, not a cryptographically secure source. Generate production keys server-side from a CSPRNG and store only a hash.

How long should an API key be?

32 random alphanumeric characters (~190 bits) or 64 hex characters (256 bits) — both far beyond guessable, and the two sizes this tool outputs. Longer adds nothing practical.

What format should my API use?

Prefixed keys are the modern default: environment and scope readable at a glance, and secret scanners can pattern-match leaks. Use hex when keys feed signing schemes, segmented when humans must transcribe them.

The Bulk UUID v4 Generator covers identifiers (which, unlike keys, aren't secrets), the Random Hash Generator produces digest-shaped values for fixtures, and the Secure Password Generator handles the human-credential side.

Open the API Key Generator, pick a format, and generate — free, instant, no signup. Your docs and fixtures get realistic keys; your real secrets stay where they belong. More tools live in the numbers category.