API Key & Token Generator: Cryptographically Secure Keys for APIs and Services
API keys and secret tokens are machine-to-machine credentials, and the standards for their quality are considerably higher than for human passwords. No password manager is involved, no human memory required, and no length limit from a web form field — the only constraints are the format requirements of the receiving service. This means there is no excuse for weak API keys, yet they remain common: developers generate them with Math.random(), use sequential identifiers, or copy examples from documentation and forget to rotate them. This generator produces API keys and secret tokens using the Web Crypto API's getRandomValues, with output formats covering the most common API key conventions: hexadecimal strings (common in webhook secrets and HMAC keys), Base64 URL-safe strings (used in JWT secrets and OAuth tokens), and alphanumeric strings (used in many SaaS API portals). Default entropy is 256 bits, matching the key strength of AES-256 and the effective security level of SHA-256 HMAC signatures.
Open Password Generator →What Is API Key & Token Generator: Cryptographically Secure Keys for APIs and Services?
An API key generator creates cryptographically secure random tokens used to authenticate machine-to-machine API requests. Output formats include hexadecimal (64 characters for 256 bits), Base64 URL-safe (43 characters for 256 bits), and alphanumeric strings. These tokens serve as bearer credentials — possession of the token grants access — so their randomness and secrecy are critical.
How to Use the Password Generator
- Step 1: Select the desired output format: hex for webhook secrets and HMAC keys, Base64url for JWT secrets and OAuth tokens, or alphanumeric for SaaS API portals.
- Step 2: Choose the entropy level — 128 bits is the minimum for most applications, 256 bits is the default and recommended for all new credentials.
- Step 3: Click Generate to produce a cryptographically random key using the Web Crypto API.
- Step 4: Copy the key and immediately store it in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler) or your password manager's secure notes.
- Step 5: Inject the key into your application via environment variables — never hardcode it in source code.
- Step 6: Regenerate and rotate the key immediately if it is ever accidentally exposed in logs, commits, or error messages.
Example
Example formats (do not use these exact strings):
Hex (256-bit): a3f7c2e1d8b4096f5a2e7c3d1b8f409a7c2e1d8b4096f5a2e7c3d1b8f40965a
Base64url: Ao_XzBmQ3VKLF4-9pTn2rEsWjIhY8gC1MDd6vNkP5Rc
Alphanumeric: K7mPr2nVqL9Xt4RwBs8Jh3Fy6Dc1Gz5Ae0QuPro Tips
- Store API keys in environment variables or a secrets manager — never commit them to source control, even in private repositories where automated scanners like GitGuardian or truffleHog can still detect them.
- Scope API keys to the minimum permissions required — a key that can only read does far less damage if compromised than one with write or admin access.
- Implement API key rotation as a standard practice: rotate all keys every 90 days, and rotate immediately after any suspected exposure.
- Use separate API keys for each environment (development, staging, production) so a key found in dev logs cannot be used against your production API.
- Log API key usage with the key's identifier (not the key itself) so you can detect anomalous usage patterns and revoke specific compromised keys without rotating all keys simultaneously.
Ready to Try It?
Free, browser-based, no signup required.
Launch Password Generator Free →FAQ's
128 bits is the accepted minimum for cryptographic security against brute force. 256 bits is the standard recommendation for new credentials, matching AES-256 key strength and providing a wide safety margin against both classical and quantum computing advances. Some frameworks like Rails generate 128-bit session secrets; for API keys you control, always generate 256 bits.
Some APIs use a two-part credential: a public API key (like a username) that identifies who is making the request, and a secret key that proves authenticity — similar to a username-password pair. The key is embedded in requests and may appear in logs; the secret must never appear in requests or logs. This generator is primarily for secrets — if you need both, generate them as separate values.
No. JavaScript's Math.random() is not a cryptographically secure PRNG — it is seeded with predictable state and produces output that can be reverse-engineered given enough samples. Use crypto.getRandomValues() in browsers, crypto.randomBytes() in Node.js, secrets.token_hex() in Python, or SecureRandom in Java for any security-sensitive token generation.
It depends on how the key is transmitted and stored. Hex is URL-safe and easy to handle in most languages (64 characters for 256 bits). Base64url is more compact (43 characters for 256 bits) and is the standard for JWTs and OAuth tokens. Alphanumeric is safe in all contexts and easiest for manual handling. All three formats represent the same entropy — choose based on your API's constraints.
Use environment variables loaded at runtime (never at build time, where they can end up in Docker images or build logs). For production systems, use a dedicated secrets manager: AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, or Azure Key Vault. These provide versioning, rotation automation, access auditing, and revocation — capabilities that environment variables alone do not provide.
Treat the key as fully compromised immediately, regardless of whether the repository is private. Revoke or rotate the key through the issuing service's dashboard before doing anything else. Then remove the key from the git history using git filter-repo (not git filter-branch, which is deprecated). Finally, scan all branches and tags for any other exposed secrets using truffleHog or GitGuardian.
Webhook secrets are typically used as HMAC-SHA256 signing keys to verify that incoming webhook payloads originate from the expected sender. A 32-byte (256-bit) hex or Base64 string is the standard format. GitHub, Stripe, and Twilio all use hex or Base64-encoded secrets of this size. Generate a new secret for each webhook endpoint and never reuse one across services.
Security frameworks typically recommend 90-day rotation for API keys as a baseline, with immediate rotation after any suspected exposure. Bearer tokens (short-lived JWTs) should expire within minutes to hours by design. Long-lived API keys that access sensitive data warrant shorter rotation windows — 30 days for payment processing or healthcare APIs is a reasonable standard.