Password Generator

What the box above just did

It drew sixteen characters, one at a time, each one independently and with equal probability from a pool of eighty-seven. That is 16 × log₂87 = 103 bits, which is the figure printed under the password. No cleverness, no word lists, no substitutions: a loop, a pool, and the browser’s cryptographic random number generator.

Sixteen is the default for a reason that changed recently. NIST Special Publication 800-63B-4, final on 31 July 2025, raised the bar that nearly every password form in the world was built against: “Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.” The familiar eight-character rule survives in that document only for passwords “only used as part of multi-factor authentication processes”. If a password is the only lock on the door, fifteen is the floor and this page starts one character above it.

The pool, exactly

Four tick boxes, four character sets, concatenated in order with no de-duplication needed because they do not overlap:

The symbol set is worth a closer look, because it is a choice rather than a standard. There are 33 non-alphanumeric printing ASCII characters. This generator uses 25 of them and omits eight: the space, ", ', /, \, `, | and ~. The repository records no reason, so none is offered here. The effect is measurable and small: each character carries 6.44 bits instead of the 6.57 a full-ASCII pool would give, costing about two bits across a 16-character password, which is the difference between 103 and 105.

It is worth knowing that the standard would rather those characters were allowed through on the receiving end. SP 800-63B-4 asks verifiers to “accept all printing ASCII characters and the space character in passwords” and to “accept Unicode characters” too. A site that rejects your generated password because of a bracket is the thing behaving badly, not the password.

Ticking a box is not a promise that the character appears

This catches people, and the explanation is more interesting than the complaint. The tick boxes decide what goes into the pool. They do not reserve a slot. Every one of the sixteen positions is an independent draw from all eighty-seven characters, so it is perfectly possible, and not even unusual, for a password to come out with no digit in it.

How unusual? With all four boxes ticked, the chance that a given output contains no digit at all is (77/87) raised to the length. At length 16 that is 14.2%, roughly one output in seven. At length 8 it is 37.7%, better than one in three. Generating 200,000 passwords at the default settings on 2 October 2026 gave 15.17% missing at least one ticked character class, which matches the arithmetic.

The temptation is to call that a defect and force one of each. Resist it. Reserving a position for a digit removes choices from that position, and removing choices removes entropy; a generator that guarantees one of each class is very slightly weaker than one that does not, and it narrows the output space in a way an attacker can model. The real cost of the current behaviour is annoyance: a site that still enforces the composition rules NIST now forbids will reject the password, and you press Generate again. That is the right trade, and it is the reason the behaviour is documented here rather than changed.

How long, in bits, and what the bits buy

Each bit doubles the work. The honest thing to say about the bottom half of that table is that the numbers stop meaning anything operational. Nobody is brute-forcing a 129-bit password; if your account is lost it will be lost to a phishing page, a reused password, or a breach at the other end, none of which care how long this string is. SP 800-63B-4 says so directly: “Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy and complex passwords as they are on simple ones.”

So the useful advice is not “go longer”. It is: go to 16 or more, never reuse it, store it in something that remembers it for you, and turn on a second factor. The length slider is the least important decision on this page.

Where the randomness comes from, and what you are trusting

Each character is chosen by asking the browser for a 32-bit random value and taking it modulo the pool size. The W3C Web Cryptography API defines the interface behind that request as “a cryptographically strong pseudo-random number generator seeded with truly random values”, and the specification advises implementers to “generate cryptographically strong random values using well-established cryptographic pseudo-random number generators seeded with high-quality entropy, such as from an operating-system entropy source (e.g., ‘/dev/urandom’)”.

That is a promise about the browser, not about this page, and the specification is unusually frank about how far it goes: it “provides no lower-bound on the information theoretic entropy present in cryptographically strong random values, but implementations should make a best effort to provide as much entropy as practicable.” Nothing in a web page can verify that its browser kept that promise. If you need a key rather than a password, note that the same specification says so itself: “Do not generate keys using the getRandomValues method.” Keys have their own interface. Passwords are what this page is for.

One honest footnote on the arithmetic. Reducing a 32-bit value modulo 87 does not divide evenly, so sixteen of the eighty-seven characters are very slightly more likely than the other seventy-one. The excess is 2.0 × 10^-8 in relative terms, and the entropy lost across a 16-character password is about 10^-13 bits. It is a real deviation from uniform and it is not a reason to regenerate anything. It is mentioned because a page that prints a bits figure owes you the places where the figure is approximate.

What this page will not do for you

It will not remember the password. Press Generate again and the previous one is gone, with no history and no undo. Copy it somewhere that will keep it before you leave.

Copy now says whether it worked. Until 7 October 2026 the clipboard write was attempted and any failure was swallowed silently, and the browser interface it uses is restricted to secure contexts, so over plain http:// the button could do nothing at all while looking like it had worked, and the next Generate then destroyed the password you believed you had. The result is now written under the entropy line either way, naming the browser's own reason when it fails, and the password is selected for you so you can copy it by hand. That line describes the password that was on screen when you pressed Copy, so generating another clears it. When the copy does work, the password is on your system clipboard, readable by other applications, and nothing clears it on a timer.

It cannot tell you whether the password is any good for the account you are about to use it on. Strength at this end is only half the problem. The other half is how the site stores it, which is where SP 800-63B-4 puts most of its demands: “Verifiers SHALL store passwords in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using a suitable password hashing scheme”, with a cost factor that “SHOULD be as high as practical” and that “SHOULD be increased over time”, and a salt of “at least 32 bits in length”. A 412-bit password stored as a bare unsalted digest is not a 412-bit password. You cannot see which one you are dealing with from the signup form.

It does not check the password against breach data. It cannot: a generated password has never existed before, so there is nothing to check. That is the advantage of generating over inventing, and it is why the strength checker is the less useful of the two pages for anything you are about to create.

Part of the QuikUtil tools collection. Generated in your browser; nothing is transmitted.

Sources

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, July 2025 (final 31 July 2025; supersedes the March 2020 edition). Established the 15-character single-factor minimum, the 8-character multi-factor minimum, the 64-character maximum verifiers should permit, the instruction to accept all printing ASCII plus space and Unicode, the prohibition on periodic rotation, the salted-and-hashed storage requirement with its cost factor and 32-bit salt, and the Appendix A statement that length and complexity do not affect phishing or keylogging. pages.nist.gov/800-63-4/sp800-63b.html
• W3C Web Cryptography API. Established the description of the random number generator, the /dev/urandom seeding advice, the absence of any entropy lower bound, the instruction not to generate keys with getRandomValues, and that crypto.subtle is secure-context-only while getRandomValues is not. w3c.github.io/webcrypto
• Electronic Frontier Foundation, “Deep Dive: EFF’s New Wordlists for Random Passphrases”, Joseph Bonneau, 19 July 2016. Established the 7,776-word list, about 12.9 bits per word, and the six-word 77-bit recommendation used in the comparison above. eff.org/deeplinks/2016/07/new-wordlists-random-passphrases
• This page’s own generator code, read and executed on 2 October 2026. Established the four set sizes and the 87-character pool, the eight omitted ASCII symbols, every bits figure in the length table, the modulo-bias magnitude, and the measured 15.17% of default outputs missing a ticked character class over 200,000 samples.

SP 800-63B-4 binds US federal agencies and the providers who serve them. Elsewhere it is adopted by choice. Nothing here is legal or compliance advice.