Password Generator
Generate strong random passwords with your browser crypto API. Choose the length, character sets, exclude look-alike characters, guarantee one of each type
Generate random passwords with the browser cryptography API rather than Math.random, so the output is suitable for real accounts. Choose the length, which character sets to include, whether to exclude look-alike characters such as l, 1, I and O, and whether to guarantee at least one character of each selected type.
The entropy figure in bits tells you how much guessing the password resists: below 60 bits is weak against a determined attacker, 80 bits is solid for a normal account, and 100 bits or more is what you want for a master password or an API key. Generating locally means the password never travels over the network, which is exactly the point.
How to generate a strong password
Choose the length and character sets
Set the look-alike and guarantee options
Copy the password and check the entropy
FAQ
How long should a password be?
Sixteen characters from mixed sets is a good default for anything important. Length adds more strength than exotic characters do, so prefer 20 characters over 12 with symbols if you have the choice.
What does the entropy value mean?
It is the number of bits of randomness in the generated password, calculated from the length and the size of the character pool. Each extra bit doubles the work needed to guess it.
Why exclude look-alike characters?
Characters such as l, 1, I, O and 0 are easy to confuse when you have to read a password from a screen and type it on a phone or into a device. Excluding them makes manual entry far less error-prone.
Is this safe to use?
The values come from crypto.getRandomValues, the browser cryptographic random source, which is the correct choice for passwords. The generation happens locally and nothing is transmitted.
Should I generate one password and reuse it?
No. Use a unique password per service and keep them in a password manager - one reused password means one breach compromises every account that shares it.
Are generated passwords stored anywhere?
No. Nothing is saved, logged or sent; if you close the page the password is gone unless you copied it.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Handling secrets safely
Developer tools process credentials more often than people realise, and the risk is not the algorithm but where the data goes. Hashing is one-way and is not encryption - MD5 and SHA-1 are broken for anything security-related, and even SHA-256 is the wrong tool for storing passwords, where bcrypt, scrypt or Argon2 exist precisely to be slow. Base64 is an encoding, not protection: anyone can decode it, so never treat it as obfuscation. A JWT can be read by anyone who holds it, which is why the payload must never contain secrets, and decoding a token does not verify its signature - verification requires the key. Everything on this site runs locally in your browser, which is the reason it can safely handle tokens and passwords at all.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.