AI API Key Generator

From your browser's Web Crypto API, specifically crypto.getRandomValues(), a cryptographically secure random number generator (CSPRNG) built into every modern browser. Characters are picked with rejection sampling, so every character in the chosen set is equally likely and there is no modulo bias. Math.random() is never used. Nothing is sent anywhere: the page's security policy blocks network requests, and you can confirm that in your browser's developer tools.

No. Those providers issue their own keys from their own dashboards, and a key made here will not authenticate with them. The presets only copy the format (prefix, length, character set) so the result looks like the real thing. They are useful for your own APIs, gateways and proxies, self-hosted model servers, mock servers, test fixtures and documentation examples. Never paste a real provider key into any website, including this one.

Aim for at least 128 bits of entropy; 256 bits leaves a generous margin. Entropy is the number of random characters multiplied by log₂ of the character-set size, so 32 hex characters give 128 bits, 22 alphanumeric characters give about 130 bits, and the default 48 alphanumeric characters give about 285 bits. The prefix is not random, so it adds no entropy. The meter on this page shows the figure for the random part only and warns you when it falls below 128 bits.

Alphanumeric and Base64URL are safe almost everywhere: HTTP headers, URLs, JSON and .env files. Hexadecimal is the most compatible but needs more characters for the same strength. The special-character set includes $ ! & * ^ #, which many shells and .env parsers treat specially, so it must be quoted and is easy to mangle; prefer Base64URL unless you have a reason not to.

Never hardcode keys in source code or client-side JavaScript. Keep them in environment variables (and keep .env out of version control) or a secret manager such as AWS Secrets Manager, HashiCorp Vault or Doppler. Use separate keys for development, staging and production, rotate them on a schedule you choose, and rotate immediately if one is ever exposed. On your server, store only a hash of each key where you can, so a database leak does not reveal usable keys.

Yes. This JavaScript uses the same approach, including rejection sampling to avoid modulo bias:

function generateKey(length = 48, charset = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789') {
  const n = charset.length;
  const limit = 256 - (256 % n);
  const buf = new Uint8Array(length * 2);
  let out = '';
  while (out.length < length) {
    crypto.getRandomValues(buf);
    for (let i = 0; i < buf.length && out.length < length; i++) {
      if (buf[i] < limit) out += charset[buf[i] % n];
    }
  }
  return out;
}

The limit check discards bytes that would make some characters slightly more likely than others.

No. Generated keys exist only in your browser's memory while the page is open, and are not written to local storage or sent to a server. The only thing the site remembers is your language choice for the menu. There are no analytics on this page, and its content security policy blocks outgoing network requests.

Key generation is disabled and the page tells you why, rather than silently falling back to Math.random() or another non-cryptographic source. Every modern browser supports it, but a security tool should never quietly produce weaker output while still calling it secure.