Security

API Key Generator

Generate random access tokens for your API. Configure prefix, length and alphabet. Everything runs in your browser using crypto.getRandomValues.

What an API key is and when to use one

An API key is a secret string a client sends with every HTTP request to authenticate. Unlike username and password, it's designed to authenticate services, not people. It usually shows up in headers like Authorization: Bearer ... or in query parameters such as ?api_key=....

API keys are great for server-to-server integrations (a script calling Stripe, a cron job pushing files to S3) and for testing tools. They're not ideal for end users — that's what OAuth or signed JWTs are for.

How we generate the key

Each character is sampled from crypto.getRandomValues, the browser's cryptographic API, mapped to the alphabet you pick:

  • Hexadecimal: 16 possible characters (0-9, a-f). 4 bits per character.
  • Base62: 62 characters (A-Z, a-z, 0-9). About 5.95 bits per character.
  • Base64 URL-safe: 64 characters (including - and _). 6 bits per character, ideal for URL tokens with no escaping.

Length and entropy guidance

An API key should carry at least 128 bits of entropy. That translates to:

  1. 32 hex characters.
  2. 22 base62 characters.
  3. 22 base64url characters.

For critical tokens (master keys, webhook keys with broad privileges) bump entropy to 256 bits: 64 hex, 43 base62 or 43 base64url. Stripe uses 32+ random characters after the prefix. GitHub PATs use 40 hex characters.

Best practices for prefixes

A readable prefix simplifies day-to-day operations. Conventions that work:

  • sk_ for "secret key" (server-side only).
  • pk_ for "publishable key" (safe in frontend code).
  • _live_ and _test_ to distinguish production from sandbox.
  • Product prefix: ghp_ (GitHub PAT), xoxb- (Slack bot).

The prefix also lets tools like GitGuardian or TruffleHog detect leaked keys in public repositories. If your prefix is generic, those scanners won't find it.

Storage and rotation

Generating the key is just the start. To make it actually safe:

  • Never commit it. Use environment variables or a secret manager (AWS Secrets Manager, Vault, Doppler, 1Password CLI).
  • Store a hash, not plaintext. If your database leaks, the keys are still useless. Show the key only once, on creation.
  • Rotate regularly. Every 90 days for production, immediately if you suspect a leak.
  • Limit scopes. A least-privilege key contains the blast radius of a leak.
  • Log usage. IP, user agent and endpoint help you spot abuse early.

Common mistakes

The same problems show up over and over in real projects:

  • API keys in the frontend JavaScript bundle.
  • "Temporary" keys shared in Slack that never get rotated.
  • One key shared across the whole team.
  • No expiration, no last-used field, no way to know if it's still active.
  • Cross-environment reuse (test key works in production).

FAQ

How long should an API key be?

At least 128 bits of entropy: 32 hex or 22 base62 characters. For critical keys, 256 bits (64 hex or 43 base62).

Which prefix should I use?

Something short that identifies environment and product: sk_live_, sk_test_, pk_. Helps log scanning and rotation.

Hex or base62?

Hex is readable and easy to inspect. Base62 packs more entropy into fewer characters and looks cleaner in URLs. Both are safe.

Is it safe to generate keys in the browser?

Yes — we use crypto.getRandomValues, which is just as robust as server-side. Nothing is sent to Genfy.