Free tool · No signup
Password & Hash Generator
Generate strong passwords, hash text or files, and create or check bcrypt hashes, all without anything leaving your browser.
Runs only in your browser. Nothing you generate or type is sent to a server, saved or added to the URL.
Your password
Generating…
Very strong
126 bits of entropy
About trillions of years to guess on average at 100 billion guesses a second, an offline attack on a fast hash. Each extra character multiplies that by 81.
Runs only in your browser. Nothing you generate or type is sent to a server, saved or added to the URL.
Hashes
MD5
…
Broken: collisions take seconds. Fine as a checksum against accidental corruption, never for security.
SHA-1
…
Broken for collisions since 2017. Still seen in Git and old systems; don't use it for new signatures.
SHA-256
…
Secure and the usual choice for checksums, signatures and HMACs.
SHA-384
…
Secure. A truncated SHA-512, so it's fast on 64-bit CPUs and resists length extension.
SHA-512
…
Secure, with the longest output here. Often faster than SHA-256 on 64-bit CPUs.
Client side only
A password generator you can't inspect is a password you have to trust someone else with, so this one never sends anything anywhere. Passwords are drawn from your browser's cryptographic random number generator, crypto.getRandomValues. SHA-1 and SHA-2 hashes use the built-in Web Crypto API, and MD5 and bcrypt run as plain JavaScript on the page. Nothing is sent to a server, saved in browser storage or added to the URL, files are read on your device rather than uploaded, and the tool keeps working with your network turned off once the page has loaded.
How the passwords are made
Each character is picked independently and uniformly from the sets you choose, using rejection sampling so no character is more likely than another. When several sets are selected, a password that misses one is thrown away and drawn again, which guarantees at least one of each without making any password more likely than the rest.
Passphrases are 3 to 12 words chosen at random from a list of 1,764 common English words, about 10.8 bits each. They're easier to type and remember than random characters of the same strength, which makes them the right choice for the few passwords you can't keep in a password manager.
What the strength rating means
Entropy is the number of guesses, as a power of two, needed to try every password the generator could have made with your settings. It describes the generator, not how the result looks, so it's only accurate for passwords made at random like these. The time to crack assumes an offline attack on a fast, unsalted hash at 100 billion guesses a second, about what one modern GPU manages against MD5. A slow hash such as bcrypt cuts that rate by a factor of a million or more.
- Under 45 bits: fine for a throwaway account behind rate limiting, not for anything that matters.
- 64 to 80 bits: strong. A 5- or 6-word passphrase sits here.
- 80 bits and up: out of reach of any offline attack. A 16-character random password is over 100.
Hashes, HMACs and checksums
A hash turns any input into a fixed-length fingerprint: change one byte and the hash changes completely. Use SHA-256 to check a download, compare files or build a cache key. MD5 and SHA-1 are still around for checksums and older systems, but both have practical collision attacks, so they shouldn't be used where an attacker could pick the input. An HMAC mixes a secret key into the hash. It's how webhook signatures from Stripe, GitHub and Shopify work: hash the raw request body with the shared secret and compare it with the signature header.
bcrypt for stored passwords
Passwords should never be stored as a plain SHA-256 or MD5. A stolen table of fast hashes can be guessed at billions of passwords a second. bcrypt is deliberately slow and salted, and its cost setting doubles the work each step, so it can keep pace with faster hardware. The bcrypt tab produces hashes in the same format as PHP's password_hash, Node's bcrypt and Apache's htpasswd -B. Use it for test users, seed data and .htpasswd files, and use your framework's own hashing for real sign-ups. For new systems, OWASP recommends Argon2id first and bcrypt where Argon2id isn't available. If you're building sign-in for a site or app, see what I build.
By Muhammad Saif · Updated
Questions, answered.
Is it safe to generate passwords and hashes online?
With this tool, yes: it's client side only. Passwords come from your browser's cryptographic random number generator (crypto.getRandomValues), and hashing runs in the browser too, with the Web Crypto API for SHA and plain JavaScript for MD5 and bcrypt. Nothing you generate or type is sent to a server, saved in browser storage or put in the URL, and files you hash are read on your device, not uploaded. You can check in your browser's developer tools: using the tool makes no network requests.
How long should a password be?
For a random password from a password manager, 16 characters or more with mixed character sets is plenty (over 100 bits of entropy). For a passphrase you have to remember, use 5 or 6 random words. NIST's guidelines (SP 800-63B) ask for at least 15 characters when a password is the only sign-in factor. Length matters more than symbols: each extra character multiplies the work of guessing it.
Passphrase or random characters?
Use random characters for anything a password manager fills in for you, and a passphrase for the few you type from memory, such as the password manager itself or your computer login. Five random words from this tool's list of 1,764 give about 54 bits; six give about 65. The words must be chosen at random, not picked by you: a phrase you make up is far easier to guess.
Which hash should I use to store passwords?
None of MD5, SHA-1 or SHA-256 on their own: they're built to be fast, so a stolen database can be guessed at billions of passwords a second. Use a slow, salted password hash: Argon2id, bcrypt or scrypt, through your framework or a maintained library. OWASP recommends Argon2id with at least 19 MiB of memory, or bcrypt with a cost of 10 or more. This tool's bcrypt tab makes hashes for test users, seed data and .htpasswd files.
Why does bcrypt give a different hash every time?
Each hash includes a new random 16-byte salt, stored in the hash itself: $2b$, the cost, then 22 characters of salt and 31 of hash. So the same password hashes differently every time, and to check a password you hash it again with the salt and cost from the stored hash, which is what the check form here does. bcrypt reads only the first 72 bytes of a password; the tool warns when yours is longer.
How do I check a downloaded file's checksum?
Choose the file in the Hash tab and paste the checksum from the download page into the compare box; the tool tells you which algorithm matches. The file is read in your browser, not uploaded. In a terminal, run sha256sum file on Linux, shasum -a 256 file on macOS, or Get-FileHash file in PowerShell on Windows. A matching SHA-256 proves the file wasn't corrupted, and that it's the one the page lists, but not that the page itself is trustworthy.
