infoOverview

Hardcoding a placeholder like "test123" as a stand-in API key works fine until it leaks into a commit, a log line, or a shared Slack thread — and unlike a real credential, it gives reviewers no signal about what a properly formed key should even look like. This tool generates cryptographically random, properly shaped key candidates on demand in Base62, hex, or UUID v4, with an optional prefix, so local development and onboarding docs can use realistic-looking keys without ever touching production secrets.

Wiring up an auth header against an in-progress API server or a mock backend rarely needs an actual key from a billing provider — it just needs something the right shape. Because generation runs client-side with cryptographically secure randomness, you can produce as many realistic-looking keys as you need without ever calling out to a third-party service.

checklistHow to Use

1. 1Pick a key shape from the Format dropdown — Base62, Hex, or UUID v4.
2. 2For Base62 or Hex, set how many characters long the key should be in the Length field.
3. 3Optionally type a tag like sk_ or api_ into the Prefix field — leave it blank if you don't need one.
4. 4Set how many keys you want in the Count field — useful for seeding a batch of test accounts in one pass.
5. 5Click Generate, then use the copy menu to grab the results as plain text, an .env block, or an MCP config snippet.

Note: switching to UUID v4 ignores the Length field entirely — output is always the fixed 36-character hyphenated form. Pick this option whenever the system on the other end expects a UUID-typed key.

menu_bookSpecifications & Glossary

• Base62: Built from the alphanumeric set [0-9A-Za-z], this is the format you'll recognize from Stripe-style keys — URL-safe with no characters that need escaping, and dense enough to pack a lot of entropy into a short string.
• Hex: Restricted to [0-9a-f], this is the same alphabet most crypto libraries emit by default — a SHA-256 digest, an HMAC signature, a randomBytes().toString('hex') call — so hex keys drop straight into code that already expects that shape.
• UUID v4: Standard RFC 4122 UUID v4 (xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx) — pick this when the system you're testing against expects a UUID column or type rather than an arbitrary string, since it slots straight into existing primary-key and request-ID fields.
• Prefix: A short tag like sk_, pk_, or api_ lets you tell secret keys apart from publishable ones at a glance — the same convention OpenAI uses with its sk-... keys — so a key pasted into a support ticket or a code review is self-documenting.
• Entropy: A 32-character Base62 string carries roughly 190 bits of entropy — log2(62) per character — which is far beyond what any brute-force attack can realistically search, even at scale.
• Randomness source: Every format draws its characters from bytes produced by the Web Crypto API's Crypto.getRandomValues, not a predictable pseudo-random generator like Math.random().
• Uniqueness: The randomness here makes collisions statistically negligible, but it doesn't enforce uniqueness the way a database constraint does. If you adopt generated keys in a real system, add a UNIQUE constraint at issuance time as well.

lightbulbUse Cases

• Generating placeholder authentication tokens and API keys while building or testing a REST API.
• Generating webhook signing secrets for local testing.
• Mocking up customer-facing API keys for a multi-tenant SaaS product before the real issuance flow is built.
• An MCP server's config file (mcp.json or similar) almost always wants an API key or bearer token in its env block — generate one here and copy it straight out as a ready-to-paste MCP Config snippet via the output card's copy menu, instead of hand-typing a fake value that might not match the expected length or charset.
• Preparing a placeholder key to sanity-check an Authorization header against a mock server or local dev environment.
• Batch-generating a set of dummy API keys as fixture data for end-to-end tests.

quizFAQ

Can I use a generated key as a real production API key?

No. This generates a randomly shaped string, not a credential registered with any payment processor, cloud provider, or third-party API. Production keys must always come from the issuing service's own dashboard. Treat anything generated here as mock data for local development and testing only.

Is uniqueness guaranteed — could two generated keys collide?

Not with a mathematical guarantee — but the underlying randomness is cryptographically secure, so collisions become statistically negligible once the key is reasonably long. If you wire generated keys into a real system, still add a UNIQUE constraint at the database layer as a backstop against the rare duplicate.

How do I choose between Base62, Hex, and UUID v4?

Base62 packs the most entropy per character, so it's the best fit for short keys in URLs or headers. Hex matches the alphabet crypto libraries already emit, so it's convenient alongside hash functions. UUID v4 is the choice when the system you're integrating with expects a standard UUID column or field. Only Base62 and Hex let you adjust the length.

What kind of string should I use as a prefix?

There's no fixed rule, but a tag like sk_live_ or sk_test_ that encodes environment or permission level makes a key self-identifying the moment someone spots it in a log or config file. Real-world setups typically use a different prefix per environment.

Are generated API keys stored or sent to a server?

No. Generation runs entirely in your browser's JavaScript, so the keys never leave your machine. Results aren't persisted anywhere — leaving the page clears them — so copy anything you need before navigating away.

Should I hash it before storing it, like a real API key?

If you adopt a value from here as a real production key rather than test data, treat it like a password: store only a server-side hash (e.g. SHA-256) and never keep the plaintext key in your database. This tool doesn't hash values itself — that's left to your backend.