API Key Generator

What this tool is used for

• Producing a key for a new integration rather than inventing a string by hand.
• Generating distinct keys per environment so a staging leak cannot reach production.
• Rotating a key that has appeared in a repository or a log.
• Producing a batch of keys for seeding a test environment.
• Generating a key in the format a particular platform expects.

Frequently Asked Questions

How long should an API key be?

At least 128 bits of entropy — 32 hex characters, or 22 Base64URL characters. Anything shorter invites brute forcing, and unlike a password an API key is used by machines, so there is no memorability cost to making it long.

How should keys be stored server-side?

Hashed, exactly like passwords — store SHA-256 of the key, compare hashes on each request. If your database is breached, plaintext keys hand the attacker every customer's access. A fast hash is acceptable here because the key is high-entropy.

Why do keys have prefixes like sk_live_?

Two reasons. It makes the key's purpose and environment obvious at a glance, preventing test keys reaching production; and it lets secret scanners (GitHub's included) recognise a leaked key by pattern and notify the issuer automatically.

Should keys expire?

Yes, and rotation should be possible without downtime — support two valid keys at once so a client can switch over before the old one is revoked. Keys that cannot be rotated never are, which is how decade-old credentials survive.

Is an API key the same as a token?

No. An API key is a long-lived shared secret identifying an application; a token (like a JWT) is short-lived, often carries claims, and is issued after authentication. Keys are simpler and correspondingly riskier when leaked.

What should happen when a key leaks?

Immediate revocation, which requires that keys be individually identifiable and revocable — one shared key across an organisation means rotating it breaks every integration at once. Per-integration keys make the blast radius small.

Why do providers scan public repositories for their own key formats?

Because a distinctive prefix makes keys findable, and the major platforms partner with GitHub to auto-revoke on detection. That is the practical argument for a recognisable prefix rather than an opaque random string.

Common errors and gotchas

• Storing the key in plaintext rather than as a hash, so a database leak hands over every key.
• Reusing one key across environments or customers, which makes revocation all-or-nothing.
• Making the key too short to resist guessing, or too long for the field that has to store it.
• Emailing or pasting a key into a ticket, after which it should be treated as compromised.
• Omitting a prefix that identifies the key's type, which makes secret-scanning much harder.