Why 32 characters by default?

A 32-character alphanumeric string provides about 190 bits of entropy — well beyond the 128-bit security level recommended for cryptographic keys. 32 characters is also a common convention for API keys (matching the hex representation of a 128-bit value) and is accepted by virtually all services.

Why no symbols in API keys?

Symbols cause problems in many technical contexts. They require URL-encoding in query strings, can break shell scripts if not properly quoted, and may be rejected by systems that expect alphanumeric-only tokens. At 32 characters, the entropy from alphanumeric characters alone is more than sufficient.

Is it safe to generate API keys in a browser?

Yes. This generator uses the Web Crypto API (crypto.getRandomValues), the same cryptographically secure random number generator your browser uses for HTTPS connections. The key is generated in your browser's memory and never transmitted anywhere. You can disconnect from the internet and the generator still works.

How often should I rotate API keys?

Rotate immediately if a key is exposed (committed to a public repo, shared in an unencrypted channel). For routine rotation, every 90 days is a common policy. Automated rotation through a secrets manager is ideal. Always have a plan for rotating keys without downtime — most services support having two active keys simultaneously for this purpose.

API Key Generator

Generate random API keys and tokens for your applications.

Length: 32

Uppercase Lowercase Numbers Symbols

Generate Random API Keys and Tokens

API keys and tokens need to be long, random, and unpredictable. Our API key generator creates cryptographically random strings using the Web Crypto API built into your browser — the same randomness source used for TLS encryption. The default 32-character alphanumeric format works with virtually any API or service. No symbols by default to avoid URL-encoding issues. Everything is generated client-side — your keys never touch a server. Need to share the key securely? Use the built-in share button to create an encrypted one-time link.

What are API keys used for?

API keys serve as authentication tokens for machine-to-machine communication. They identify your application when calling external services — payment processors, cloud platforms, email delivery services, databases, and third-party integrations. Unlike user passwords, API keys are typically stored in environment variables, configuration files, or secrets managers and are never typed by hand. This is why length and randomness matter more than memorability. A 32-character alphanumeric key provides about 190 bits of entropy — far more than any attacker can brute-force.

API key best practices

Never hard-code API keys in source code — they end up in version control history even if you delete them later. Use environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler). Rotate keys periodically and immediately if a key is exposed. Use different keys for development, staging, and production environments. Set the most restrictive permissions possible for each key. Monitor API key usage for anomalies. When sharing keys with team members, use encrypted one-time links instead of Slack messages or emails that remain in chat history.

How to share API keys with your team

Sharing API keys through Slack, email, or team chat is one of the most common security mistakes in software development. These messages persist in search history, backups, and third-party data exports. Instead, use the "Share as link" button above to create an encrypted one-time link. The recipient clicks the link, copies the key, and the link self-destructs. The key is encrypted end-to-end so even our server never sees the plaintext. For ongoing team access, use a secrets manager that provides audit logs and role-based access control.

Token formats for different use cases

Different systems expect different token formats. For general API keys, 32-character alphanumeric strings (our default) work everywhere. For URL-safe tokens, avoid symbols since characters like + and / need percent-encoding. For JWT secrets, use 32+ characters for HMAC-SHA256. For database passwords, 24-32 alphanumeric characters are typical. For webhook signing secrets, 32-64 characters is standard. Adjust the length slider above based on your needs — when in doubt, longer is better.

Frequently asked questions

Why 32 characters by default?: A 32-character alphanumeric string provides about 190 bits of entropy — well beyond the 128-bit security level recommended for cryptographic keys. 32 characters is also a common convention for API keys (matching the hex representation of a 128-bit value) and is accepted by virtually all services.
Why no symbols in API keys?: Symbols cause problems in many technical contexts. They require URL-encoding in query strings, can break shell scripts if not properly quoted, and may be rejected by systems that expect alphanumeric-only tokens. At 32 characters, the entropy from alphanumeric characters alone is more than sufficient.
Is it safe to generate API keys in a browser?: Yes. This generator uses the Web Crypto API (crypto.getRandomValues), the same cryptographically secure random number generator your browser uses for HTTPS connections. The key is generated in your browser's memory and never transmitted anywhere. You can disconnect from the internet and the generator still works.
How often should I rotate API keys?: Rotate immediately if a key is exposed (committed to a public repo, shared in an unencrypted channel). For routine rotation, every 90 days is a common policy. Automated rotation through a secrets manager is ideal. Always have a plan for rotating keys without downtime — most services support having two active keys simultaneously for this purpose.