What Is a Developer Credential?
A developer credential is a random secret value used by software to authenticate a request, sign a payload, or protect a session — rather than a password a human types in. These values are typically stored in environment variables or configuration files and used programmatically. Because nothing needs to type or remember them, they can and should be much longer and more random than a human password.
What Is an API Secret?
An API secret is a private value your own application uses to authenticate its requests or sign outgoing data. This tool generates a random secret suitable for that purpose in your own systems — it does not create or register an official API key with any third-party provider such as AWS, Stripe, or Google. Those keys are issued directly by each provider's own system and can't be generated from outside it.
What Is a Webhook Secret?
Many services let you configure a shared secret that's used to sign webhook payloads, so your endpoint can verify a request genuinely came from that service rather than an impostor. This tool generates a long, random value suitable for that purpose. You'll typically paste it into the sending service's webhook configuration and your own verification code.
What Is a Session Secret?
Many web frameworks use a secret value to sign or encrypt session cookies, so a client can't tamper with session data undetected. This tool generates a random value suitable for that role. Exact requirements — minimum length, expected format — vary between frameworks, so check your specific framework's documentation before relying on a generated value here.
Hex vs. Base64URL: Which Should You Use?
Both encode the same kind of random bytes, just differently. Hex represents each byte as two characters from 0–9 and a–f, so it's twice as long as the underlying byte count but uses only 16 possible characters — simple, predictable formatting that's easy to work with in any language. Base64URL packs more information per character (64 possible characters per position), producing a shorter string for the same number of underlying random bytes, and uses only characters safe to place directly in a URL or a header value without additional encoding. Neither is more "secure" than the other for the same byte count — the choice comes down to what format your system expects.
| Format | Character set | Best for |
|---|---|---|
| Hex | 0-9, a-f | Simplicity, database keys, log-friendly values |
| Base64URL | A-Z, a-z, 0-9, -, _ | Compact tokens, URLs, HTTP headers |
| Alphanumeric | A-Z, a-z, 0-9 | Systems that reject symbols entirely |
Why Cryptographically Secure Randomness Matters
A secret is only as strong as the process that generated it. If an attacker could predict
or narrow down the possible outputs of your random generator, the secret's length stops
mattering. This tool draws every value from the Web Crypto API's
crypto.getRandomValues(), the same category of randomness used for
encryption keys, rather than a general-purpose random function.
Why Math.random() Is Not Suitable for Secrets
JavaScript's built-in Math.random() is a fast, general-purpose pseudorandom
function, not designed with security in mind. In several JavaScript engines its internal
state can be inferred from observed outputs, which is irrelevant for a game or animation
but disqualifying for anything protecting a real system. This generator never calls
Math.random() for any credential value — you can confirm this directly
by viewing the page source.
How Browser-Based Generation Works
Every credential on this page is generated by JavaScript running in your own browser tab.
Random bytes come from crypto.getRandomValues(), and are then formatted as
hex, Base64URL, or a custom character set entirely on your device. No network request is
made to generate a value, which you can verify yourself by watching your browser's network
activity while using this tool.
How to Store Secrets Safely
- Keep secrets in environment variables or a dedicated secrets manager, not committed to source control.
- Use different secrets for development, staging, and production environments.
- Rotate a secret immediately if you suspect it has been exposed.
- Limit who and what has access to production secrets on a need-to-know basis.
Never Share Secrets Publicly
A secret pasted into a public repository, a support ticket, a chat message, or a screen share is effectively compromised the moment it's visible to anyone outside its intended system. Treat any exposed secret as burned and rotate it, rather than assuming a quick deletion undoes the exposure — copies and caches can outlive the original message.