8-128 characters
Common: sk_, pk_, api_
1-50 keys
Usage Tips
JWT Secret: Use at least 256 bits (32 characters) for HMAC-SHA256 signing.
API Key: Add a prefix like sk_live_ for production or sk_test_ for testing.
Security: Store keys securely. Never expose secrets in client-side code.
UUID: Use for unique identifiers. Collision probability is negligible.
What is API Key Generator?
An API key generator produces cryptographically random strings that serve as unique identifiers and authentication tokens for client applications accessing web services. API keys come in several formats depending on the use case: UUID v4 provides standardized 128-bit identifiers with negligible collision probability, random alphanumeric strings work well for simple bearer tokens, hex-encoded keys pair naturally with cryptographic operations, and base64-encoded secrets are the standard for JWT HMAC signing. Well-designed API key systems often include a human-readable prefix (like sk_live_ or pk_test_) that communicates the key type and environment at a glance, making debugging and key rotation significantly easier in production systems.
How to Use
- Pick the key format that matches your authentication scheme — UUID for distributed IDs, random string for bearer tokens, or JWT secret for token signing
- Adjust the character length based on your security requirements; longer keys provide more entropy and resist brute-force attacks better
- Add a descriptive prefix like sk_prod_ or pk_dev_ so team members can identify the key's purpose and environment from logs
- Set the batch quantity when provisioning keys for multiple clients or rotating credentials across services
- Click Generate, then copy individual keys or the entire batch for integration into your application's environment configuration
Why Use This Tool?
Tips & Best Practices
- For JWT HS256 signing, use at least 256 bits of entropy (32 bytes) — shorter secrets can be brute-forced offline
- Adopt Stripe-style prefixes (sk_live_, sk_test_, pk_live_) so you can distinguish production from test keys in application logs
- Never commit generated secrets to source control; inject them through environment variables or a secrets manager at deploy time
- Rotate API keys on a regular schedule and maintain a grace period where both old and new keys are valid
- UUID v4 is ideal for database primary keys in distributed systems because it requires no coordination between nodes
Frequently Asked Questions
What is the difference between UUID v4 and a random string?
UUID v4 follows the RFC 4122 specification, embedding version and variant bits at fixed positions, which makes the identifier self-describing and interoperable across systems. A plain random string has no structural constraints and can use any character set or length. Choose UUID when you need standardized uniqueness guarantees; choose random strings when you control both producer and consumer and want maximum flexibility.
How strong should my JWT secret be?
The secret length must match the hash algorithm's output size. For HS256, use at least 256 bits (32 bytes); for HS512, use 512 bits. The secret must be generated with a cryptographically secure random number generator — never use a password, dictionary word, or predictable pattern. An undersized secret allows attackers to forge valid tokens by brute-forcing the signing key offline.
Why add prefixes to API keys?
Prefixes serve as immediate visual metadata. When a key appears in server logs, error reports, or configuration files, a prefix like sk_live_ instantly tells you it is a secret key for the production environment. This prevents accidental use of a test key in production, speeds up incident response, and mirrors the convention used by Stripe, AWS, and other major API platforms.
When should I NOT use this tool?
Do not use this generator for keys that protect highly sensitive data in production environments. The browser's Math.random() is not cryptographically secure, and the output could theoretically be predicted. For production secrets, use a server-side cryptographic library (Node.js crypto, OpenSSL) or a managed secrets service like AWS Secrets Manager or HashiCorp Vault.
Is my data private when using this tool?
Yes. All key generation runs entirely in your browser using client-side JavaScript. No generated key is ever transmitted to any server, logged, or stored. The tool has zero backend dependencies, so your credentials remain completely local to your device.
What is the AWS-style key format?
AWS access keys follow a specific 20-character format starting with AKIA for long-term credentials or ASIA for temporary (STS) credentials. The remaining 16 characters are uppercase letters and digits. This format is recognized by AWS SDKs and IAM policies, making it useful when you need to test IAM key validation logic without hitting real AWS endpoints.
Real-world Examples
Provisioning API keys for a SaaS platform
When onboarding a new customer, you generate a secret key with a prefix that identifies the environment and a random string that provides the entropy needed for secure authentication.
Type: API Key | Prefix: sk_live_ | Length: 32 | Quantity: 3
sk_live_a8Kj3mNx9QpW7vRt2YcB5nLf sk_live_F4gH6iJ0kL2oP8qS1uV3xZ7d sk_live_E9wA5bC0dF6gH2iJ4kL8mN0o
Generating a JWT signing secret for HS256
A Node.js API needs a base64-encoded secret of at least 256 bits to sign JSON Web Tokens using the HMAC-SHA256 algorithm.
Type: JWT Secret | Length: 32
dG9rZW4tc2VjcmV0LWZvci1oczI1Ni1zaWduaW5n