Random Secret Generator — JWT, API Keys, Hex + Base64
Random secret generator online — generate cryptographically secure JWT secrets, API keys, webhook signing keys. Hex, Base64, prefix presets. Free.
Quick presets
Result will be 64 characters of hex (256 bits of entropy).
Generated locally in your browser using crypto.getRandomValues() — the same CSPRNG that backs WebAuthn, TLS, and key generation in Web Crypto. Secrets are never sent to PDFFlare or any server, and are not stored in localStorage (only your format / length / prefix preferences are remembered).
PDFFlare's random secret generator produces cryptographically secure secrets in any format your stack expects: hex, base64, base64url, or alphanumeric. Use it as a jwt secret generator (HS256 / HS384 / HS512), an api key generator online for your own services, a webhook signing secret generator (Stripe-style whsec_ prefix included), or a generic random hex string generator for encryption keys, salts, and CSRF tokens. Secrets are generated locally with crypto.getRandomValues(); nothing is transmitted.
One-click presets cover the common cases: JWT HS256 (256-bit base64), JWT HS512 (512-bit base64), API key (256-bit base64url with api_ prefix), Stripe webhook (whsec_ + 256-bit hex), AES-256 encryption key (256-bit hex). Or configure manually with bit length (128 / 192 / 256 / 384 / 512), format, prefix, and bulk quantity (1 / 5 / 10 / 25 / 50). Pair the generated key with PDFFlare's HMAC Generator to sign webhook payloads, the JWT Decoder to inspect tokens you sign with it, or the Password Generator for human-readable credentials instead.
Acts as a secure random string generator, encryption key generator online, and random base64 string generator — all in one page. Free, unlimited, no signup. Preferences persist across reload via localStorage; generated secrets never do.
How to Generate a Random Secret
Pick a preset (or skip if you know what you need)
Click JWT HS256 secret, API key, Stripe webhook secret, AES-256 encryption key, or JWT HS512 secret to set the right length and format with one click. Or configure manually below.
Choose length and format
Bit length controls entropy — 256-bit (32 bytes) is the standard for JWT HS256, Stripe signing keys, and most API tokens. Pick a format: hex (most common), base64 (JWT secrets), base64url (URL-safe / JWT signature side), or alphanumeric (clean tokens with no symbols).
Add a prefix if needed
Pick a prefix to mimic Stripe (sk_live_, sk_test_), GitHub PATs (ghp_), webhook secrets (whsec_), generic API keys (api_), or enter a custom prefix like mykey_. Useful when your code looks for a specific format.
Generate, copy, paste into your .env
Click Generate. Each secret has its own Copy button; if you generated multiple, Copy all puts them on the clipboard newline-separated. Paste into your .env, JWT_SECRET environment variable, or wherever your code reads the secret. The page never sees the values.
When Do You Need a Random Secret?
JWT signing key for your API: JWT HS256 needs a 256-bit shared secret to sign tokens. Use the JWT HS256 preset, paste the result into JWT_SECRET in your .env, and your tokens are cryptographically authentic. Switch to JWT HS512 if your auth library is configured for it. The same secret signs and verifies, so both your API server and your auth service need to read it from the same env var.
Webhook signing secret (Stripe / GitHub / Slack-style): When you send webhooks to clients, sign each payload with an HMAC of the body using a secret you share with the receiver. Use the Stripe webhook secret preset (whsec_ + 256-bit hex) for Stripe-style format, or pick whichever prefix matches your convention. Pair this with PDFFlare's HMAC Generator to test your signing logic.
API keys for a service or beta launch: Need to mint 50 API keys for a beta cohort? Pick the API key preset, set quantity to 50, click Generate, copy all. Each key is a 256-bit base64url string with an api_ prefix — long enough to be unguessable, URL-safe enough to embed in headers without escaping, and recognizable by prefix when scanning logs.
Encryption keys for AES-256, libsodium, or KMS imports: AES-256 needs a 256-bit key. Use the AES-256 encryption key preset for 64 hex characters that you can paste into an HSM, KMS, or encryption library directly. For libsodium's secretbox you may want base64 instead — just switch format to Base64 and the same 32 random bytes encode differently.
Why Use PDFFlare's Random Secret Generator?
Cryptographically Secure
Uses crypto.getRandomValues() — the W3C Web Cryptography CSPRNG that backs WebAuthn and TLS. Not Math.random(). Alphanumeric mode uses rejection sampling for zero modulo bias.
One-Click Presets for the Common Cases
JWT HS256 / HS512 secrets, API keys (api_ prefix + base64url), Stripe webhook secrets (whsec_ prefix), AES-256 encryption keys. Five presets cover 90% of what most engineers need.
100% Browser-Based
Secrets generate locally — no request to PDFFlare, nothing transmitted, nothing logged. Verify by checking DevTools → Network. Your format / length / prefix preferences persist across reload; the secrets themselves never do.
No Signup Required
Free, unlimited, no account. Bulk generate up to 50 at once, copy individually or all-at-once newline-separated. Plus 5 formats × 5 lengths × 7 prefixes = the right combination for almost any use case.
Frequently Asked Questions About Random Secret Generator
Use PDFFlare's random secret generator with the JWT HS256 secret preset — it produces a 256-bit base64 string from `crypto.getRandomValues()`, the same CSPRNG that backs WebAuthn and TLS in your browser. Copy the result into your application's `JWT_SECRET` environment variable or secrets manager. Because the secret is generated locally, nothing is ever transmitted — open DevTools → Network and you'll see zero requests during generation. For HS512, switch to the JWT HS512 preset for a 512-bit secret.
RFC 7518 (JOSE) requires HS256 secrets be at least 256 bits (32 bytes). HS384 needs 384-bit minimum, HS512 needs 512-bit. PDFFlare's presets default to those exact sizes. Going larger doesn't add meaningful security — once your secret matches the algorithm's hash output size, more bytes are unused. Going smaller (e.g., a 128-bit JWT secret for HS256) is technically allowed but reduces brute-force resistance and is flagged by JOSE-compliant libraries.
Both. The API key preset produces a base64url-encoded 256-bit secret with an `api_` prefix that's URL-safe and easy to spot in logs. If you'd rather have a clean alphanumeric token, switch the format to Alphanumeric — produces A-Z, a-z, 0-9 with no symbols, ideal for tokens that pass through systems that mangle `+` `/` `=`. Length, prefix, and format are all independently controllable.
Use the Stripe webhook secret preset — it produces a `whsec_` prefix plus 32 bytes of hex, mimicking the format Stripe (and many other webhook providers) ships. Or pick the prefix yourself from the Prefix dropdown (Stripe live, Stripe test, GitHub PAT, webhook signing, API key, custom). Then sign your outgoing webhooks with the secret using PDFFlare's HMAC Generator — same key, same algorithm, byte-perfect signatures.
Yes — the tool uses `crypto.getRandomValues()`, the W3C Web Cryptography API CSPRNG. Browsers seed it from the OS entropy pool (`/dev/urandom` on Linux/Mac, BCryptGenRandom on Windows) and produce values suitable for cryptographic use. This is NOT `Math.random()`, which is not cryptographically secure and should never be used for secrets. The alphanumeric mode uses rejection sampling on byte values < 248 to eliminate modulo bias, so every character is uniformly distributed.
Yes — pick 5, 10, 25, or 50 from the quantity dropdown. Each secret is generated independently from a fresh `crypto.getRandomValues()` call. Useful for seeding a service that needs N pre-generated tokens, rotating credentials in batch, or generating a pool of API keys for a beta launch. The Copy all button puts them on the clipboard newline-separated for easy paste into a config file.
No. Generation happens in your browser via `crypto.getRandomValues()`. The secret never leaves your machine — it's not transmitted, not logged, not stored. Only your format / length / prefix preferences are persisted in localStorage so the next visit lands you on the same configuration. Open DevTools → Application → Local Storage and you'll see only those preference keys, never a generated secret.
Same entropy, different encoding. Hex (lowercase or UPPERCASE) is the most universal — every tool reads it. Base64 is denser (4 chars per 3 bytes) and is what most JWT libraries expect for HS256/HS512 secrets. Base64url replaces `+/` with `-_` and drops `=` padding so it's safe to use in URLs and JWT signature segments. Alphanumeric (A-Z, a-z, 0-9) avoids symbols altogether — useful when the secret will pass through systems that escape special characters poorly. Pick the one your downstream tool expects.
Use this for SYSTEM secrets (JWT signing keys, API keys, webhook signing keys, encryption keys) where humans never need to type or remember the value. For HUMAN passwords (account login, email, master passwords), use PDFFlare's Password Generator at /tools/dev/password-generator — it has memorable-passphrase modes, optional special characters, and length suited for human typing. The two tools optimize for different use cases.
UUIDs are structured identifiers (16 bytes with version + variant bits) intended to be unique, not unguessable. Use a UUID when you need a database primary key or request ID. Use a random secret when you need authentication material — API keys, signing secrets, encryption keys. UUIDs have only 122 bits of randomness (the rest are version/variant flags); a 256-bit random secret has 256 full bits and is the right tool for cryptographic use.