Security
Free API Key Generator Online
Generate API keys in various formats: UUID-style, hex, base64, prefixed. Cryptographically random.
What is an API key?
An API key is a secret credential that identifies and authenticates a client making requests to an API. Unlike passwords (which authenticate humans), API keys authenticate applications, services, and automated systems. They are the most common authentication mechanism for REST APIs because they are simple to implement, easy to include in request headers, and straightforward to rotate.
This generator creates cryptographically secure API keys using the Web Crypto API — the same entropy source used for TLS keys. Keys generated here are safe for production use as API secrets, webhook secrets, and access tokens.
All generation happens locally in your browser. No key is ever sent to any server. You can use this tool offline with the same results.
API key formats compared
Different API key formats have different trade-offs for readability, security scanning, and compatibility:
Pros: Immediately identifiable; scannable by secret scanning tools (GitHub, GitLab); distinguishes test vs live keys; Stripe, Supabase, and most modern APIs use this format.
Cons: Slightly longer; prefix must be kept consistent.
Best for: New APIs where developer experience matters; public SDKs; anywhere you want automatic secret scanning.
Pros: Universally recognised format; compatible with UUID columns in databases; human-readable groupings; widely supported in frameworks.
Cons: Not all characters are random (4 version bits and 2 variant bits are fixed); not prefixed so harder to identify in code.
Best for: Systems already using UUIDs for IDs; simple internal APIs; rapid prototyping.
Pros: Compact; universally safe in URLs, headers, and JSON; easy to store; exactly 128 bits of entropy.
Cons: Shorter — 128 bits is secure but some high-security applications prefer 256 bits.
Best for: CSRF tokens; short-lived session identifiers; any context where compactness matters.
Pros: Maximum entropy from this tool; 256 bits is the standard for cryptographic keys; future-proof.
Cons: Longer string to store and transmit; visual inspection is impractical.
Best for: Signing secrets; HMAC keys; JWT secrets; root API secrets for administrative operations.
Pros: Same entropy as Hex 64 in fewer characters; URL-safe; used in JWTs; no padding characters.
Cons: Slightly less readable than hex; not universally understood by developers.
Best for: JWT secrets; OAuth tokens; situations where URL-safety and compact size both matter.
Implementing API key authentication
A secure API key system has seven components:
- 1Key generation
Generate 32+ bytes from a CSPRNG. Use this tool or crypto.randomBytes(32) in Node.js, secrets.token_hex(32) in Python.
- 2Show once
Display the full key to the user exactly once at creation. Prompt them explicitly to save it — it will never be shown again. This is the GitHub and Stripe model.
- 3Hash before storage
Store SHA-256(key) in the database. Never store the plaintext key. On authentication, hash the incoming key and compare to the stored hash.
- 4Accept in headers
Use the Authorization: Bearer <key> header (standard OAuth 2.0 format) or a custom X-API-Key header. Never accept keys in URL query parameters — they appear in server logs and browser history.
- 5Rate limiting
Apply per-key rate limits to prevent abuse. Redis is ideal for sliding window rate limiting — store request counts keyed by the hashed API key.
- 6Audit logging
Log every API request with the key ID (not the key itself), timestamp, IP address, endpoint, and response code. This enables security auditing and anomaly detection.
- 7Rotation support
Allow users to generate new keys and set an expiry date for old ones. Implement a grace period where both old and new keys work, then automatically revoke the old key.
API key vs JWT vs OAuth — when to use each
Use when: Server-to-server communication, developer APIs, simple integrations. Best when the client is a server (not a browser) and you control both sides.
Limitation: No built-in expiry; no standard user identity claims; harder to scope granularly.
Use when: Stateless user authentication, microservices, mobile apps. Best when servers need to verify tokens independently without a database lookup.
Limitation: Cannot be revoked without infrastructure; payload is readable (not encrypted by default).
Use when: Third-party access delegation ("Login with Google"), when users grant an app access to their data on another service.
Limitation: Complex to implement correctly; requires an authorization server; more moving parts.
Use when: Traditional web applications where the server controls all state. Simplest to implement correctly; trivial to revoke; no JWT pitfalls.
Limitation: Requires server-side session store; stateful; CSRF protection needed.
API key security best practices
Use environment variables and .env files. Add .env to .gitignore before your first commit. Use tools like gitleaks, truffleHog, or GitHub's built-in secret scanning to detect accidentally committed keys. If a key is committed, rotate it immediately — treat it as compromised even if the repo is private.
Enable GitHub's secret scanning (free for public repos) or install gitleaks as a pre-commit hook. Many formats — including the prefixed format generated by this tool — can be automatically detected and alerted on before they reach production.
Keys with recognisable prefixes (sk_, pk_, api_) can be automatically detected by secret scanning tools. Stripe pioneered this approach and GitHub natively scans for Stripe key patterns. When you design your key format, choose a prefix and register it with GitHub's secret scanning partner program.
API keys should have the minimum permissions needed for their use case. A key used only to read data should not be able to write or delete. Implement permission scopes at the key level, not just the user level, so a compromised key has limited blast radius.
Set up alerts for: sudden spikes in request volume, requests from unusual geographies, requests to endpoints a key has never hit before, and authentication failures. Automatic key suspension on anomaly detection can contain a breach before it becomes serious.
For generating the underlying random bytes for your key system, use the Random Token Generator. For signing API requests with HMAC, use the HMAC Generator. For UUID-based identifiers, see the UUID Generator.
FAQ
Common questions
Are the generated API keys cryptographically secure?
Yes. All keys are generated using the Web Crypto API (crypto.getRandomValues() and crypto.randomUUID()), which uses the operating system's CSPRNG — the same entropy source used for TLS keys and SSH keys. Keys generated here are safe to use in production as API secrets.
Which API key format should I use?
Use Prefixed format when you want Stripe-style keys (sk_live_..., pk_test_...) that are immediately identifiable and can be scanned for in code. Use UUID v4 for distributed systems where UUID compatibility matters. Use Hex 64 or Base64url for maximum entropy in a compact format. Hex 32 is a good choice for keys that will appear in URLs or headers.
What is a prefixed API key and why use prefixes?
A prefixed key has a short identifier before the random part, like sk_a1b2c3... (secret key) or pk_a1b2c3... (public key). Prefixes serve three purposes: they identify the key type at a glance, they allow scanning tools to detect accidentally committed keys in source code (GitHub has built-in scanning for many prefixes), and they enable users to distinguish between test and production keys.
How do I store API keys securely in my application?
Never hardcode API keys in source code. Use environment variables (.env files) locally and a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical) in production. Add .env to .gitignore and use pre-commit hooks to scan for leaked secrets. In the database, store a hashed version of the key for lookups — never the plaintext key.
Should I hash API keys before storing them in a database?
Yes, for production systems. Store a SHA-256 hash of the key in the database, not the plaintext. Show the full key to the user exactly once (at creation time) and prompt them to save it. On subsequent API requests, hash the received key and compare to the stored hash. This means a database breach does not expose usable keys. GitHub, Stripe, and most major API providers follow this pattern.
How often should I rotate API keys?
Rotate API keys: immediately if they are suspected to be compromised, when a team member with access leaves, and as part of regular security reviews (every 90–180 days for sensitive keys). Use key rotation strategies that allow both old and new keys to work simultaneously during the transition period, then revoke the old key after confirming the new one is in use.
What is the difference between a public key and a secret key in API authentication?
In split-key schemes (like Stripe): a publishable/public key (pk_...) identifies your account and can safely appear in client-side JavaScript. A secret key (sk_...) authorizes privileged operations and must only appear on your server. This is not the same as asymmetric cryptography — both keys in this context are random strings, just with different permission levels.
How do I implement API key authentication in my application?
Standard implementation: 1) Generate a secure random key (32+ bytes). 2) Show the full key to the user once. 3) Store SHA-256(key) in the database with associated user ID and permissions. 4) Accept the key in an Authorization header (Bearer <key>) or X-API-Key header. 5) On each request, SHA-256 hash the received key and look it up in the database. 6) Check rate limits, expiry, and permissions before processing the request.
More in Security