API Key Generator

What is an API key?

An API key is a random string that a client sends with each request to prove it is allowed to call an API. From the server's perspective, whoever holds the key is trusted. That makes an API key a bearer credential: like a house key, anyone who picks it up can use it, so it has to be treated with the same care as a password.

Common shapes: sk_live_... and pk_live_... from Stripe, ghp_... from GitHub, xoxb-... from Slack. The prefix is a namespace convention. The random part after it is what does the work.

API key vs password

A password identifies a human. It gets combined with a username, hashed with a slow function (bcrypt / argon2), and stored so nobody but the human can log in. Passwords are typically short and memorable because a human has to enter them.

An API key identifies a program. Nobody remembers it. Nobody types it. It gets pasted into an environment variable or a secret manager, loaded at runtime, and sent as an Authorization header. Because no human is in the loop, an API key can be long and high-entropy without any UX cost. That is why they usually are.

API key best practices

• Never commit a key to Git. Use a .env file that is gitignored, and pull secrets from your platform's secret manager (AWS Secrets Manager, GitHub Actions secrets, Vercel env vars, Amplify env vars).
• Rotate regularly. Every 90 days is a reasonable default. Every time someone leaves the team is mandatory.
• Use least privilege. If the key only needs read access, do not give it write. If it only needs one endpoint, do not give it the whole API.
• Distinguish secret from public keys. A pk_ key is safe in browser JS. An sk_ key must live server-side only. Confusing them is the most common leak.
• Watch for accidental logging. Log middleware that dumps request headers will happily write your API key to CloudWatch. Filter Authorization before it hits the logs.
• Revoke on suspicion. If a key ever appears in a public repo, a stack trace, or a chat message, rotate it immediately. Do not wait to confirm compromise.

How much entropy do you actually need?

Entropy in bits is the log base 2 of the number of guesses an attacker needs. Every extra bit doubles the work. Here is the ladder:

• 40 bits — local scripts, throwaway dev keys. Guessable in a day on a modest GPU.
• 80 bits — production API keys. Years to brute-force offline, out of reach for any online attacker.
• 128 bits — JWT signing secrets, OAuth client secrets, AES-128 encryption keys. Out of reach for anyone short of a nation-state.
• 256 bits — long-lived encryption keys, HMAC-SHA512 secrets. What NIST recommends for anything you plan to still trust in twenty years.

The suitability grid in the tool updates live as you tweak length and charset, so you can see the moment your settings cross each threshold.

How this tool handles your data

• Every key is generated in your browser via crypto.getRandomValues. Not Math.random, not any pseudo-random algorithm, and not on our server.
• The validator also runs locally. What you paste into the analyzer stays in the tab.
• The QR code is drawn to an in-page canvas by a client-only library and downloaded from a data URL. Nothing is uploaded.
• The site uses Google Analytics for page-view counts. It does not observe key input or output.
• Open DevTools → Network before you generate anything. You will not see a request go out.

Frequently asked

How secure is this generator?

Every key is generated in your browser using crypto.getRandomValues, the Web Crypto API that also backs TLS key generation and WebAuthn. It is not Math.random and it is not a pseudo-random algorithm. Modulo bias is avoided via rejection sampling. There is no server call at any point — you can verify by opening DevTools → Network before you press Generate.

Are the keys stored anywhere?

No. They exist in your browser tab until you close it. Nothing is written to any server, log, cookie, or database. This site uses Google Analytics for page-view counts only and does not observe the generated values.

What length should I use?

For a typical API key, 32 characters with mixed classes gives you around 200 bits of entropy — vastly more than any online attacker will crack. For a JWT signing secret, use 48 or 64 characters. For an encryption key, 64 or more.

What is the difference between URL-safe and standard?

Standard mode draws from uppercase, lowercase, numbers, and a broad symbol set. URL-safe mode uses only the base64url alphabet: A-Z, a-z, 0-9, hyphen, underscore. That guarantees the key survives being pasted into a URL, a JWT, or an environment variable that will later be shell-expanded.

Can I use this for JWT secrets?

Yes. For HS256, aim for at least 32 characters (256 bits when using URL-safe). For HS512, use 64 or more. The suitability grid at the top of the page tells you live whether your current settings meet the JWT threshold.

Can I generate OAuth client secrets with this?

Yes. Most OAuth 2.0 client secrets are 128+ bits of entropy — you get that from 22+ characters at full entropy or 43+ URL-safe characters. The prefix option is useful here (e.g. oauth_secret_).

What does the sk_ / pk_ prefix do?

It is a cosmetic namespace, popularised by Stripe. sk_ = secret key (server-side, never expose), pk_ = public / publishable key (safe in client-side code). The prefix does not add entropy; it is a signal to your future self and your teammates about how the key should be handled.

Why does the entropy number matter?

Entropy in bits equals the log2 of the number of guesses an attacker needs. 80 bits takes years to brute-force even offline. 128 bits is out of reach for any classical attacker, including nation-states. Adding one bit doubles the work. Adding one character of length adds log2(pool_size) bits.