Every key produced here is random. None of them will authenticate against the provider they imitate. What they reproduce is the *shape* — the prefix, the length, the character set — which is exactly what you need to test the systems that look for keys.
What this is for
Testing secret scanners. Before you trust a pre-commit hook or a CI scanner, feed it keys in each format you care about and confirm it fires. A scanner nobody has tested against real-looking input is a scanner nobody knows the behaviour of.
Writing detection rules. Building a regex against one hand-typed example produces a pattern that matches one string. Generating fifty and testing against all of them finds the edge cases in your character class and length bounds.
Fixtures and documentation. Test suites, API documentation, onboarding screenshots and demo environments all need credential-shaped strings. Using a real key — even an expired test key — is how real keys end up committed.
Training and exercises. Security awareness material and incident response drills need realistic artefacts. A drill using YOUR_KEY_HERE teaches nobody to recognise the real thing.
Formats included
The generator reproduces prefixes and lengths for OpenAI project keys, Anthropic API keys, Stripe secret and publishable keys, GitHub classic and fine-grained tokens, AWS access key IDs and secret access keys, Slack bot tokens, SendGrid, Google API keys and Twilio SIDs. Each one notes what distinguishes it — for example, that AKIA marks a long-lived IAM key while ASIA marks a temporary STS credential.
Why real keys will not match some checks
Several providers append a checksum to the random body. GitHub tokens carry a CRC32 in their final characters, which is why GitHub's own scanning can distinguish a genuine token from a random string with the right prefix. A key generated here has a random body, so it passes prefix-and-length checks but fails checksum validation. That is the correct behaviour for test data — and if your detector validates checksums, it should reject these.
Frequently asked questions
Could one of these accidentally be a real key?
No. The probability of randomly generating a valid key is the same as guessing one, which is why keys work at all. These are as safe to publish as any random string.
Why not just use the provider's documented example key?
Documented examples are widely known and often allowlisted by scanners specifically because they appear in so much documentation. That makes them useless for testing detection — your scanner may be configured to ignore them.
Will these pass my provider's client-side format validation?
Usually yes, which is the point. They match the prefix and length that SDKs check before making a request. They will fail at the API with an authentication error.
How do I test the other direction — that my scanner does not fire on safe values?
Generate keys here, then run the credential regex tester against a mix of real-looking keys, commit SHAs, UUIDs and base64 blobs. A good pattern catches the first group and ignores the rest.