Free tool· Security & keys
Generate keys, secrets and UUIDs — the openssl way, in your browser
Random bytes in hex, base64 or raw, UUID v4 and v7, prefixed API tokens with checksums, JWT HMAC secrets and RSA, ECDSA, Ed25519 or X25519 key pairs as PEM, JWK and OpenSSH — each with the matching command-line equivalent.
- Runs in your browser
- Free, no signup
- Updated
Options
256 bits of randomness.
Encoding
Up to 100 at once.
Result
256 bits of randomness…
Command-line equivalent
$ openssl rand -hex 32
About this tool
What is the Random Key Generator?
The Random Key Generator is a free tool that creates cryptographically secure keys and secrets in your browser: random bytes in hex, base64 or raw, UUID v4 and v7, prefixed API tokens with checksums, JWT HMAC secrets and RSA, ECDSA, Ed25519 or X25519 key pairs as PEM, JWK and OpenSSH — each with the matching openssl command.
- Price
- Free
- Signup
- None
- Your data
- Stays in your browser
- Updated
What you get
- Random bytes as hex, base64, base64url or .bin
- UUID v4 and time-ordered UUID v7
- API tokens with prefix and CRC-32 checksum
- HS256/384/512 secrets, also as JWK
- RSA, ECDSA, Ed25519 and X25519 key pairs (PEM, JWK, OpenSSH)
- Matching openssl and ssh-keygen commands
Security & keys · no account, nothing uploaded
How it works · three steps, no signup
How to use the Random Key Generator
Step 1: Choose what you need
Random bytes, a UUID, an API token, a JWT signing secret or a full public/private key pair.
Step 2: Set the format
Pick the length and encoding — hex, base64, base64url, raw bytes, PEM, JWK or an OpenSSH authorized_keys line.
Step 3: Copy, save or reproduce
Copy or download the result, or run the matching openssl or ssh-keygen command to make the same kind of key on a server.
Good to know
Where your keys come from — and where they go
Random values come from crypto.getRandomValues and key pairs from your browser's WebCrypto implementation — the same operating-system generator that openssl and ssh-keygen use. Nothing on this page makes a network request with your keys: there is no server side to the tool at all.
Private keys are exported as unencrypted PKCS#8 PEM, the format most libraries load directly. If you keep one on disk, protect it with file permissions or convert it to an encrypted PEM withopenssl pkey -in private.pem -aes256 -out private.enc.pem.
Building on the WhatsApp Cloud API? A 32-byte random value is a good verify token for your webhook subscription, and the webhook signature verifier can check incoming X-Hub-Signature-256 headers against your app secret.
FAQ
Random Key Generator: questions and answers
Is a key generated in the browser as secure as openssl rand?
The randomness is equivalent: crypto.getRandomValues and WebCrypto draw from the operating system's cryptographically secure generator, the same source openssl uses. The difference is where the secret ends up — here it exists in one browser tab until you copy or save it. For a production server's private key, generating it on that server with the openssl command shown keeps it off every other device.
How long should an API key or HMAC secret be?
Use at least 128 bits of randomness for tokens and session secrets — 32 random base62 characters is about 190 bits. For HMAC and JWT signing, match the hash output: 32 bytes for HS256, 48 for HS384 and 64 for HS512. Longer keys add nothing; shorter ones weaken the signature.
UUID v4 or UUID v7 — which should I use?
v4 is 122 random bits and reveals nothing, which suits public identifiers. v7 begins with a millisecond timestamp, so IDs created later sort later — that keeps B-tree database indexes compact and makes inserts faster at scale. The trade-off is that a v7 UUID discloses roughly when it was created.
Why put a prefix and checksum on API tokens?
A recognisable prefix such as sk_live_ lets secret-scanning tools and code reviewers spot a leaked key instantly, and tells your team which environment it belongs to. A checksum — here a CRC-32 encoded in the last six characters — lets your server reject mistyped or truncated keys before touching the database. It is a typo check, not a security control.
Which key pair type should I pick?
Ed25519 is the modern default for SSH and signatures: short keys, fast, hard to misuse. ECDSA P-256 is the most widely supported elliptic-curve choice for TLS and ES256 JWTs. RSA 2048 or larger remains the most compatible option for older systems and RS256 JWTs. X25519 is for key agreement in encryption protocols, not for signing.
Still have questions?
Book a demoMore free tools
Keep your stack sharp
Ready to do this at scale?
InfiQ puts broadcasts, chatbots, a shared inbox and the developer API behind one dashboard — on the official WhatsApp Business API. 7-day free trial, no card required.