Dev
Random API Key Generator (Developer)
API documentation and test fixtures that use unrealistic key formats — all lowercase, obviously short, clearly fake — erode developer trust and sometimes break format-validation code that runs in tests. This generator produces properly formatted API keys in five styles that match real-world conventions, so your docs and fixture files look authoritative. The Key Style selector determines the format. Hex-32 produces a 32-character lowercase hex string (128 bits of entropy), similar to an MD5 hash in appearance. Hex-64 doubles that to 64 characters (256 bits), matching the security baseline most production APIs target. Base58-32 uses the Bitcoin Base58 alphabet — alphanumeric without 0, O, I, and l to avoid visual ambiguity — producing 32 characters. Prefixed style generates keys like sk_live_XXXX, pk_live_XXXX, api_XXXX, or tok_XXXX with a 32-character Base58 body, closely matching Stripe and similar payment API key formats. UUID-style outputs standard v4 UUIDs for services that use UUID-based API keys. All generation happens client-side in the browser and is never transmitted anywhere. Keys are safe to publish in public README files, open-source test fixtures, and OpenAPI specs — they carry no real credentials or account access.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set the count field to however many keys you need, such as 10 for a fixture file with multiple test users.
- Open the style dropdown and select the format that matches your target API — hex-32, hex-64, Base58, prefixed, or UUID.
- Click Generate to produce the full batch of randomly formatted API keys instantly.
- Review the output list and click Copy to transfer all keys to your clipboard in one action.
- Paste the keys directly into your test fixture file, markdown documentation, or environment config.
Use Cases
- •Seeding a multi-tenant staging database with unique per-row API credentials using a batch of 50+ keys
- •Writing OpenAPI/Swagger spec examples that show correctly formatted hex-64 or Base58 key values
- •Testing authentication middleware in Jest with fixture keys that match real format-validation regex
- •Mocking Stripe payment flows in a sandbox app using prefixed sk_live_... style secrets
- •Filling placeholder credentials in a public GitHub README without exposing any real secrets
Tips
- →When documenting a third-party API integration, match the generator's style to that API's real format so readers aren't confused by mismatched examples.
- →Generate at least 20 keys when seeding a test database — having extras avoids re-running the generator mid-setup if you miscounted rows.
- →Prefix hex keys manually with a service identifier like myapp_ before pasting into docs; it makes fixture keys self-documenting.
- →Use UUID-style keys only for documentation examples, never as a stand-in for a real security design — their fixed structure signals low entropy to any reviewer.
- →For parameterized tests, generate a batch equal to your test case count, then assign one key per case to ensure each test runs with a unique credential.
- →If your validation regex rejects generated keys, the mismatch itself is a useful finding — it may reveal a bug in your key-format assumption.
FAQ
are randomly generated API keys safe to use in public repos or open-source docs
Yes. Every key is generated entirely in your browser and never sent to any server or stored anywhere. They have no association with a real service, account, or credential, so publishing them in a public README, OpenAPI spec, or open-source test fixture carries zero security risk.
what is the difference between hex-32 and hex-64 api keys
Hex-32 produces a 32-character string representing 128 bits of entropy, visually similar to an MD5 hash. Hex-64 doubles that to 256 bits, which matches the security baseline most production APIs target. Choose hex-64 for docs that should reflect a properly secure key length, and hex-32 when matching a specific service that issues shorter keys.
which key style should I use to mock Stripe or similar payment API keys
Choose the prefixed style, which outputs keys in the sk_live_... pattern Stripe uses. The prefix combined with a Base58-encoded body avoids ambiguous characters like 0, O, and l. If your code runs a format-validation check on incoming keys, the prefixed style is the closest match without requiring a real Stripe account.
which key style has the most entropy and is best for security documentation
Hex-64 provides 256 bits of entropy and is the strongest option the generator offers. Base58-32 provides approximately 190 bits (log2(58^32)), which is also production-strength. UUID-style provides 122 bits of randomness (the remaining bits are fixed version and variant). For security documentation that should model best practices, use hex-64 or Base58-32.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.