Password Tools: Generator & Entropy Tester
By Alex • Published: 4 April 2025 • Updated: 5 December 2025
Two small browser tools to help you create and assess strong passwords: a cryptographically sound password generator, and a local entropy tester that estimates how resistant a password is to brute force.
The generator uses crypto.getRandomValues() to build passwords from configurable character
sets, with options for easier typing or extra strength. The entropy tester applies a straightforward
formula based on the character set and length to give an estimate in bits, alongside a simple
“recommended / not recommended” judgement that lines up with the examples further down this page.
Everything runs entirely in your browser: no passwords are transmitted or stored anywhere. These tools are designed to be simple, transparent helpers rather than full password managers, so you can see exactly how they behave, cross-check against the example table, and combine them with your own policies and threat model.
You’ll also see why this site does not treat the popular “three random words” slogan as a magic solution. It was designed as usable baseline advice for the general public, but under realistic attack models a typical three-random-words password can sit in the region of ~60 bits of entropy – in our estimates, roughly “a couple of weeks” of cracking – which is nowhere near the “centuries” people often assume. The sections below walk through the numbers, recommendations, and finally how the randomness behind the generator itself is sanity-checked.
At a glance
- Cryptographically sound password generator and entropy tester, both running locally.
- Slider-controlled password length up to 100 characters.
- Toggle for easier typing or extra-strong character sets.
- Entropy estimator with simple “recommended / not recommended” feedback.
- All processing is local to your browser; nothing is uploaded.
- Built-in randomness health check using the same API as the generator.
You are responsible for how and where you store any generated passwords. Avoid re-using passwords across accounts and enable multi-factor authentication wherever possible.
Interactive password tools
Password Generator
Generate a random password locally in your browser. When you’re happy with it, you can send the result straight into the entropy tester on the right to see roughly how hard it is to brute force.
[password]
For most cases, aim for at least 16 characters. For passwords you never type (e.g. stored only in a password manager), much longer is better – and you can see that reflected in the entropy numbers you get from the tester and in the example table below.
Password Entropy Estimator
Estimate the entropy of a password using a simple character-set × length formula. It’s the same model used in the “Illustrative examples” table further down, so you can compare your own passwords against the scenarios there.
Minimum recommended entropy here is 100 bits for high-value accounts – that’s the “centuries” bracket in the table.
For a more advanced view, you can also compare results with tools like the Bitwarden password strength tester . The idea is that all of these should roughly agree that high-value accounts deserve high-entropy, manager-generated passwords.
Context and recommendations
The generator and tester above give you numbers; this section is about what those numbers mean. Passwords are one of many forms of authentication, and one of the simplest ways to protect accounts and information. They are ultimately limited by time and compute power: given enough time (and poor settings), a password can be cracked by brute force. Increasing entropy – randomness and length – is how you push that time into the “not worth it” zone.
Entropy is measured in bits and reflects how many possible combinations a given password could have. Roughly speaking, every extra bit doubles the search space. A small increase in length or character set can translate into a large increase in the time needed to exhaust all possibilities, which is why the example table jumps from seconds to years as you move down it.
For high-value accounts or long-term secrets, aim for passwords that are randomly generated, unique to that service, and stored in a reputable password manager. For anything you have to type frequently – especially on mobile – you may prefer slightly easier character sets, but compensate with more length. The entropy tester is there to help you quantify those trade-offs.
Rules of thumb
- Use unique passwords for every account.
- Use a password manager to generate and store long, random passwords.
- Aim for >= 100 bits of entropy for high-value accounts.
- Avoid patterns, personal data, and common phrases.
- Enable multi-factor authentication wherever possible.
For more detailed guidance, see standards such as NIST SP 800-63B/-63B-4 and the NCSC’s public guidance on passwords (including “three random words”) – but treat “three random words” as a minimum baseline, not an end goal. The examples below show why.
Illustrative examples (estimates)
The table below uses the same simple entropy model as the tester above
(log2(charsetSize) × length) and a rough mapping
to “time to crack”. These are illustrative, not guarantees, but they show how quickly entropy climbs – and
why three random words land around the “weeks” range rather than “centuries”.
| Description | Password | Bits of Entropy | Est. Time to Crack |
|---|---|---|---|
| Most “common password” | 123456 |
19.93 | 1 second |
| A typical randomly generated 8-character password | Nc.x90-X |
52.44 | 3 hours |
| Following the NCSC recommended “three random words” | poachrubycoma |
61.11 | 14 days |
| Following Forbes “how to create a strong password” | G7&d#4kzL1! |
72.10 | 4 months |
| Randomly generated 10-character password | o95_/upw-%JJ |
78.66 | 3 years |
| Password with over 100 bits of entropy | MfN&q~WJqWzt4-\v |
104.87 | Centuries |
The “three random words” example above sits around 61 bits and an estimated ~14 days in this simple model. In reality, attackers don’t brute-force every possible string; they use dedicated passphrase attack wordlists and tuned cracking rules. Knowing that many people follow the “three random words” pattern shrinks the real search space further, so offline cracking against a stolen hash can be significantly faster than these estimates suggest.
Why “three random words” isn’t enough on its own
The NCSC’s original three random words advice was a huge step up from “Winter2024!” and recycled football-team-plus-number passwords. It gave non-technical users something they could actually remember, and for a lot of low-value accounts that’s still a huge improvement.
But from a security-nerd perspective, it has hard limits. A typical three-word passphrase chosen from a
relatively small dictionary and glued together in a predictable way (no spaces, no symbols, all lowercase)
is exactly what modern cracking rigs are optimised for. Once an attacker has your password hash, they don’t
blindly try “every 14-character string” – they throw tuned passphrase dictionaries and rules at it,
targeting patterns like wordwordword. Under those conditions, what looks like “two weeks” in
a model can be brought down to days or less.
So on this site the rule of thumb is: treat three random words as a floor, not a target. It’s far better than weak, reused passwords – but for anything you truly care about, a long, random, manager-generated password with >= 100 bits of entropy plus multi-factor authentication is the bar to aim for. Use three random words only where usability absolutely dominates and the risk is genuinely low.
Password recommendations
Your circumstances and the security required will determine the entropy you really need. As a conservative default, aim for randomly generated passwords with at least 100 bits of entropy for any account where compromise would hurt (financial, email, cloud storage, identity, etc.). You can use the generator and tester at the top of the page to reach that region.
At a minimum, we’d recommend using a password manager (for example KeePassXC) to generate and store unique, long passwords that combine upper and lowercase letters, numbers, and symbols. If you need to type the password on a phone or TV, you can trade some character-set complexity for extra length – but avoid “cute” constructions that fit obvious three-word patterns.
To learn more about modern password thinking, see NIST’s Digital Identity Guidelines (SP 800-63B-4) and the NCSC’s password advice. Both now emphasise length, blocklists of known-bad passwords, and usability over old-school “must contain a symbol” rules.
Randomness, trust, and my background
All of the generator’s strength ultimately depends on one thing: the quality of the random numbers it
uses. Under the hood, this page relies on window.crypto.getRandomValues(), which is the
browser’s cryptographically secure random number generator (CSPRNG). Modern browsers are required to route
this call to the operating system’s own CSPRNG (for example /dev/urandom on Unix-like systems
or the appropriate Windows APIs), rather than weaker sources like Math.random().
I built this with a Computer Security background rather than just “I read somewhere this was secure”. I completed a BSc (Hons) in Computer Security, including modules such as:
- Secure Design, Testing and Programing – covering secure software design, Programing and testing, and critical thinking about how secure programs actually work.
- Mathematical Tools for Computer Security and Forensics – covering the mathematical side of security, including how to reason about randomness, distributions and proofs that underpin cryptographic primitives and forensic tools.
- Cyber Tools and Processes – covering use of Passware to break into encrypted files and archives, giving me experience of how quickly weak or patterned passwords fall to wordlists with GPU backed machenes and how password cracking works in legal law enforcment scanarios.
As part of building this page, I generated large samples from crypto.getRandomValues()
in my own environment and ran basic statistical tests (frequency distribution, Shannon entropy, etc.).
The outputs behaved as you would expect from a healthy CSPRNG – no obvious bias, entropy close to the
theoretical maximum for the sample size. That doesn’t “prove” the CSPRNG is perfect, but it does give
additional confidence that what the browser is exposing behaves like proper random data, and motivates
the live health check in the next section.
Critical Evaluation
The live randomness sanity check below uses the same API as the password generator and runs
simple tests on a fresh sample from crypto.getRandomValues():
- Counts how often each byte (0–255) appears in the sample.
- Computes the approximate Shannon entropy of the distribution.
- Flags obviously strange behaviour (e.g. missing values, very low entropy).
If your browser or environment were catastrophically broken, there’s a good chance this would look obviously wrong (very low entropy, severe bias, or repeated values). Subtle cryptographic weaknesses are far harder to detect and are outside the scope of a small page like this, but for normal users on mainstream browsers this should provide a sensible extra layer of transparency about the randomness feeding the generator.
These checks only detect obvious failures such as severe bias, low entropy or repeated values. It cannot uncover deeper cryptographic flaws, OS-level RNG issues, or targeted compromise. It also does not validate the security of your device, browser, extensions or network environment.
Cryptographic Randomness Health Check
Live test of crypto.getRandomValues()
This tool takes a fresh sample of random bytes from
crypto.getRandomValues() – the same source used by the generator – runs a couple of basic
statistical checks, and reports whether anything obviously wrong shows up.
When you load this page, it runs once automatically. You can re-run it below if you want to see how different samples behave.
Show test details
If this test ever reports a serious issue, it could indicate a broken browser environment or a non-standard implementation. In that case, avoid relying on in-browser password generation and use a dedicated password manager instead.
Histogram of observed values
Based on 1,000 random integers in the range 0–100, grouped into ten bins. For healthy randomness, the bars should be roughly level with each other – you’re looking for “nothing weird”, not a perfectly flat line.
If one bar is dramatically higher or lower than the others in repeated tests, that suggests bias and you should treat this environment with caution. On a typical modern browser you should see minor wobble between runs, but no persistent, glaring outliers.
Contact and share
Questions?
If you have feedback, ideas for improvements, want to sanity-check a password policy, or have any questions about how these tools work under the hood, feel free to get in touch.