Numbers
API Token Pair Generator
An API token pair generator creates matching public and secret key pairs that mirror the authentication patterns used by production services like Stripe, Twilio, and SendGrid. Each pair consists of a public key that identifies the client and a secret key that signs or authenticates requests — a structure developers encounter constantly but rarely have good dummy data for. This generator lets you produce realistic-looking pairs instantly, with full control over prefix, length, and quantity. The prefix field is where the most practical value lives. Services like Stripe use `pk_test_` and `sk_test_` to visually distinguish key types at a glance. By setting your own prefix here — whether `pk`, `api`, `pub`, or something domain-specific — you produce token pairs that look structurally identical to what your real system will eventually issue. That matters when writing documentation, building UI mockups, or training teammates on how keys should be handled. Token length directly affects the entropy of the generated value. At 32 characters, an alphanumeric token carries roughly 190 bits of entropy, which is well above the threshold for most API key systems. Shorter lengths work fine for low-stakes demos; longer ones are worth using when the mock data needs to pass validation regex in a real codebase. Generate several pairs at once to populate seed files, fill out Postman environments, or build out multi-tenant test fixtures without manually crafting each key. The output is formatted consistently so you can paste it directly into a config, spreadsheet, or onboarding guide with minimal cleanup.
How to Use
- Set the prefix field to match your system's naming convention, such as pk, api, or pk_test_.
- Adjust the token length to match your system's validation requirements — 32 is a safe default.
- Set the count to how many pairs you need, then click Generate to produce all pairs at once.
- Copy individual pairs or the full list and paste them into your config file, seed script, or documentation.
Use Cases
- •Seeding a Postman environment with realistic test API credentials
- •Populating a multi-tenant dev database with per-account key pairs
- •Building UI mockups that display real-looking API key management screens
- •Writing SDK documentation with plausible example credentials
- •Testing regex validation logic that checks key prefix and length
- •Creating onboarding guides showing developers how to store keys securely
- •Filling staging environment config files before real keys are provisioned
- •Demoing an API key dashboard to stakeholders without exposing real secrets
Tips
- →Use pk_live_ and pk_test_ prefixes to generate separate fixture sets for production-mirror and test environments.
- →Set length to exactly match your regex validator so generated keys pass format checks without editing.
- →Generate 10+ pairs at once when seeding a multi-tenant database — each pair is independent and ready to assign.
- →Pair this with a .env template: generate keys here, paste them in, and commit the template without values.
- →Avoid length values below 24 characters — short keys look unrealistic and may fail minimum-entropy checks in auth libraries.
- →For SDK documentation, use a consistent prefix like pk_example_ to make it obvious these are not real credentials.
FAQ
What is an API token pair and how does it work?
An API token pair consists of a public key and a secret key. The public key is safe to include in client-side code or logs — it identifies who is making a request. The secret key must stay server-side only; it's used to sign requests or authenticate the caller. Exposing the secret key is equivalent to handing over account access.
Are the generated tokens safe to use in production?
No. The generator uses Math.random(), which is not cryptographically secure. For production systems, generate tokens using a CSPRNG: Node.js crypto.randomBytes(), Python's secrets module, or a similar platform equivalent. Use this tool only for development, testing, documentation, and demos.
Why does the secret key get a different prefix than the public key?
The generator automatically mirrors common API conventions: pk becomes sk, pub becomes sec. This matches how services like Stripe distinguish key types visually. It makes the generated pairs immediately legible — anyone reading the key knows its role before doing anything else.
What token length should I use?
32 characters is a solid default — roughly 190 bits of entropy from an alphanumeric character set, which exceeds NIST recommendations for API keys. Use 48 or 64 characters if your system's validation logic expects longer keys, or if you want the mock data to pass length checks in a real codebase without modification.
Can I use a prefix like pk_test_ to match Stripe's format?
Yes. The prefix field accepts any string, so entering pk_test_ will produce keys like pk_test_a3Fz... and sk_test_a3Fz... — structurally identical to Stripe's test credentials. This is useful when building integrations or writing documentation where format fidelity matters.
How many pairs can I generate at once?
The count field controls how many pairs are produced per generation. Generating 10 or 20 at once is practical for seeding a database fixture or populating a spreadsheet. Each pair is independently generated, so there's no relationship between them beyond sharing the same prefix and length.
What character set do the tokens use?
Tokens are generated from alphanumeric characters (A-Z, a-z, 0-9), which is standard for API keys. This avoids special characters that can break URL encoding, config file parsers, or shell variable assignments — common pain points when using purely random byte strings.
How do I store or handle the secret key safely in a real app?
Never hardcode secret keys in source code or commit them to version control. Store them in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler). Rotate keys if they're ever logged or accidentally exposed, and scope permissions as narrowly as possible per key pair.