Random Password Generator
Free, browser-based generator for passwords, passphrases, AES encryption keys, UUIDs, and API tokens, built on the Web Crypto API. Nothing you generate here ever leaves your device.
Generator tool
NIST SP 800-63B-4 recommends 15+ characters when a password is your only login factor.
Not sure whether to use the password or passphrase mode? See Password vs Passphrase.
Generating a WiFi password specifically? The dedicated WiFi Password Generator stays within the WPA2/WPA3 8-63 character limit and avoids ambiguous characters by default.
Generating a master password for a password manager? Use passphrase mode at 6+ words, or character-password mode at 20+ characters. It's the one password you'll actually type and remember, so passphrase mode is usually the easier choice, and it doesn't need to change from what's already here.
Equivalent command: openssl rand -hex 32
Need a key for a specific framework instead? See dedicated generators for Django, Rails, or NextAuth, or browse the full Secret Key Generators hub.
For signing webhook payloads, API requests, and other message authentication. The standard convention ties key length to the hash's own output size, not an arbitrary number.
Building or verifying a JWT instead of a standalone HMAC secret? See the JWT Builder panel or the JWT Decoder.
Not sure which version to use? See UUID v4 vs v5 vs v7 vs ULID vs NanoID compared. Need to generate UUIDs in your own code instead? See guides for Python, Java, or JavaScript, or visit the full UUID Generator hub.
Equivalent command: openssl rand -hex 16
Need a cryptographic salt instead of a general random string? A salt is exactly this: random bytes, not secret, just unique per credential. NIST SP 800-132 sets 16 bytes (128 bits) as the standard minimum for password-hashing salts. Set the length above to 16 and the Hex bytes format, and this panel produces one directly.
For banking PINs, device unlock codes, and numeric 2FA, generated with the same CSPRNG as every other tool here, not Math.random(). Length matters more than you'd think: a 4-digit PIN has only 10,000 possibilities, which a determined attacker with physical access can brute-force in minutes. 6+ digits is a meaningfully better floor where the option is available.
Curious why the random source matters here? See What Is a CSPRNG?
Looking to encode or decode text instead of hashing it? Try the Base64 / URL Encoder. Encoding is reversible, hashing isn't.
Just need one algorithm on its own page? See dedicated SHA-256 and MD5 generators.
This checker never transmits what you type, anywhere. Every check runs in this page's own JavaScript. That's different from breach-checking tools that call an external API with your password, even a partial hash of it. We deliberately don't do that here, so this can't tell you if a password has appeared in a known breach. It can tell you length, character variety, and whether it matches an all-too-common pattern.
This checker applies the current federal length guidance. See NIST's 2025 Password Rule Change for what changed and why.
Generates standard TOTP/HOTP codes per RFC 6238 / RFC 4226, the same algorithm used by Google Authenticator, Authy, and most "scan this QR code" 2FA setups. Everything, including the secret, is computed locally. Nothing is sent anywhere.
Builds and signs an HS256 (HMAC-SHA256) JSON Web Token entirely client-side. For testing and development only. For production auth, issue tokens from your own signed-in server, never a public web page.
Have a token and need to inspect it instead? Use the JWT Decoder.
How this tool works
Every value this page generates comes from your browser's own Web Crypto API, specifically crypto.getRandomValues() for passwords, passphrases, encryption keys, API keys, and hex strings, and crypto.randomUUID() for UUIDs/GUIDs. Both are specified to return cryptographically strong random output, unlike Math.random(), which is not suitable for security purposes. That's the same class of mechanism described in NIST's recommendations for deterministic random bit generators. See What Is a CSPRNG? for the full explanation, including a live side-by-side demo and a real recent example of what goes wrong when this distinction gets ignored.
One nuance worth being upfront about: MDN's own documentation notes that for values you'll use directly as a non-extractable cryptographic key inside the Web Crypto API, SubtleCrypto.generateKey() is the preferred method, partly because it's guaranteed to run in a secure context. This tool exports plain hex/Base64 text you can paste into another system's config or codebase, the common real-world reason to use a browser key generator, so getRandomValues() is the right tool for that job. If you're generating a key to use directly inside a Web Crypto application, use generateKey() instead.
On the topic of secure contexts: crypto.getRandomValues(), which powers the Password, Passphrase, Encryption Key, API Key, and Random String/Hex panels, doesn't actually require HTTPS. It's the one member of the Crypto interface specified to work in both secure and insecure contexts. crypto.randomUUID() and crypto.subtle (used for hashing, TOTP/JWT signing, and UUID v5) are the parts that genuinely require a secure context and won't work without HTTPS. This site is served over HTTPS throughout, so none of this affects anything here. It's just worth knowing precisely which piece needs what, rather than treating "HTTPS required" as a blanket rule for the whole API.
- NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, csrc.nist.gov
- MDN Web Docs, Crypto: getRandomValues() method, developer.mozilla.org
- MDN Web Docs, Crypto: randomUUID() method, developer.mozilla.org
- MDN Web Docs, Crypto interface, secure-context requirements per member, developer.mozilla.org
- NIST SP 800-63B Revision 4, Digital Identity Guidelines: Authentication and Authenticator Management (password length guidance used in the Password/Passphrase panel), csrc.nist.gov
Frequently asked questions
Does RandomKeyGenerator.com store or transmit anything I generate?
No. Every value is generated by JavaScript running in your own browser. Nothing is sent to a server, logged, or saved after you leave or refresh the page. Read more about how and why we built it this way.
Is this actually cryptographically secure, or just "random-looking"?
The Web Crypto API's getRandomValues() method is specified to return cryptographically strong random values, a different category from Math.random(), which is not cryptographically secure. See the sources linked above.
Should I use an online generator for production encryption keys?
For personal and development use, a client-side generator like this is fine, since the key never leaves your browser. For production secrets protecting real systems, many security teams still prefer generating keys locally (e.g. with OpenSSL or a language's built-in secrets module) simply to avoid depending on any third-party page at all. This tool is built so you can verify nothing leaves your browser. That verification is still worth doing yourself for anything mission-critical.