A bulk password workflow generates a fresh, unique password for every account by repeatedly rolling a cryptographically secure random string — and the safest way to do that is one password at a time, copied and stored before the next click, so nothing ever leaves your device. The word "bulk" describes a workflow rather than a server-side batch: each click of Generate produces an independent high-entropy string, built from the character pool you choose and never transmitted over the network. Strength is measured in bits of entropy, where each character contributes roughly log2(poolSize) bits to the total. With uppercase, lowercase, digits, and symbols all enabled, the pool is 86 characters and each character adds about 6.4 bits, so a 16-character password carries roughly 103 bits of entropy — comfortably past the 100-bit threshold that standard password-security guidance treats as strong against offline brute-force attacks. This guide walks through the workflow, the entropy math, and the local-only design that keeps every generated password private.
What "Bulk" Generation Looks Like With a Local Tool
Most "bulk password generator" pages on the web promise to spit out hundreds or thousands of passwords in a single click and hand you a downloadable file. That is a valid workflow — but it also means trusting a server to generate credentials you are about to paste into real accounts, and then trusting that server to delete every trace afterwards. The Password Generator takes a different path: it produces a single password per click, runs entirely in your browser, and never transmits the result anywhere. To build a batch you click Generate, copy the result, paste it into your password manager, label the entry, and click again. There is no upload step, no server log, and nothing to clean up when you close the tab.
That changes who the tool is for. If you need a thousand throwaway codes for a single onboarding event, a server-side batch exporter is the right pick. If you need a small set of strong, long-lived master passwords — or a few dozen unique credentials for accounts you actually own — repeatedly using a local tool gives you higher entropy per password and zero network exposure. The randomness comes from your own device's crypto.getRandomValues, and the result stays in your tab until you copy it. The privacy story is not "trust the vendor"; it is "the vendor never sees the secret."
How to Generate Multiple Strong Passwords
The full workflow takes only a few seconds per password once you have your settings dialed in. Run through these steps for each new credential you need.
- Open the Password Generator in your browser. No login, no extension, no download — just the page.
- Set the length first using the slider or the number box. The practical default is 16 characters; longer is stronger because entropy scales with length. Use 20 or more for master passwords and account-recovery codes you may one day have to type by hand.
- Toggle the character types you want included: uppercase (A–Z), lowercase (a–z), digits (0–9), and symbols (!@#$…). Enabling all four gives the widest pool — 86 distinct characters — and the most entropy per character position.
- Decide whether to exclude ambiguous characters. Toggling off 0, O, 1, and l trades a small amount of entropy for passwords that are dramatically easier to read and transcribe. Leave them on if you only ever copy-paste.
- Read the strength and entropy estimate. The tool reports entropy in bits; aim for 100 bits or more for accounts that matter, and treat anything under 60 bits as weak.
- Click Generate to roll a fresh password from the CSPRNG. The tool uses rejection sampling so every character in the pool is equally likely, guarantees at least one character of each selected type, then shuffles the result with Fisher–Yates so the guaranteed characters are not pinned to predictable positions.
- Click Copy, then paste the password into your password manager and label the entry. Closing or refreshing the tab discards the password from memory; the only copy that survives is the one you saved.
- Repeat from step 6 for every additional password you need. Each click is independent — there is no shared seed between rolls, so no two passwords are correlated and an attacker who sees one cannot infer the others.
Entropy by the Numbers: Length vs. Character Variety
The single biggest lever in password strength is length, not character variety. The table below shows how the character pool changes as you enable more sets; the entropy per character grows slowly (about 1.0 bits when you add uppercase to lowercase, for example), while adding a single character to the length multiplies the total search space by the entire pool size.
| Pool size | Characters included |
|---|---|
| 10 | Digits only (0–9) |
| 26 | Lowercase letters (a–z) |
| 52 | Lowercase + uppercase |
| 62 | Lowercase + uppercase + digits |
| 86 | Lowercase + uppercase + digits + symbols |
Modern guidance from NIST SP 800-63B and OWASP favors long passwords or passphrases over forced complexity rules for exactly this reason. A 20-character string drawn only from lowercase letters falls just short of the 100-bit threshold (about 94 bits), while an 8-character string jammed full of symbols does not. When you generate a batch, hold length constant (say, 16 or 20 characters) and treat character variety as a secondary refinement — useful for raising entropy further, but never a substitute for length. For a deeper look at why uniform selection and an unbiased PRNG matter as much as the headline entropy number, see what makes a random string secure.
Why a CSPRNG Beats Math.random
Most casual "random password" snippets online call JavaScript's Math.random. It is fast, it is convenient, and it is not cryptographically secure. Its output is generated by an internal PRNG state that can be reverse-engineered from a handful of prior values, which means anyone who has seen a few outputs from the same session can predict the next ones. Passwords built on Math.random therefore carry far less real randomness than their length suggests, even when the length looks impressive on screen.
The Password Generator uses the platform's CSPRNG instead — the browser's built-in crypto.getRandomValues, which MDN describes as letting you get "cryptographically strong random values." Strength comes from two layers on top of that. First, rejection sampling ensures every character in the pool is picked with exactly equal probability, eliminating the modulo bias that a naïve mapping of 32-bit random numbers onto a smaller alphabet would create. Second, a Fisher–Yates shuffle runs after at least one character of each selected type is guaranteed, so those guaranteed characters do not sit in fixed positions where an attacker could exploit the pattern. Together those details are what make the reported entropy number a real description of the search space rather than a marketing label.
Storing Many Unique Passwords Without Losing Track
The point of generating a fresh password per site is nullified the moment you start reusing them, or worse, writing them on a sticky note. NIST SP 800-63B and the OWASP Authentication Cheat Sheet both recommend a long, random, unique password for every account, kept in a password manager rather than memorized. A manager removes the only real friction in the workflow: you do not have to remember a 20-character string of random characters because the manager fills it in for you, and you do not have to type them by hand on every login.
Two habits make the bulk workflow sustainable. First, prefer the password manager's built-in generator when one is available, because it can save the new password to the right entry in a single step. Use the standalone Password Generator when you need a portable, device-agnostic string — a master password, a Wi-Fi pre-shared key, a recovery code you may one day have to type on a borrowed device — because the result never leaves your tab. Second, treat each generated password as single-use: paste it into the target account immediately, save it in your manager, and do not store it anywhere else. Because generation happens locally and the password is never transmitted, the only place it can leak from is the device you generated it on, which is why a full-disk password and a locked-screen policy still matter even with a local-only tool.
When Excluding Ambiguous Characters Helps
The exclude-ambiguous toggle removes 0, O, 1, and l from the pool. This is a usability trade, not a security gain. It costs you only a fraction of a bit per character — the pool drops from 86 to 82 — but produces strings that are dramatically easier to read aloud, type on a phone, or transcribe from a printed backup sheet. Reach for it when the password may one day be entered by hand: recovery codes, Wi-Fi keys you share with guests, the master password for the password manager itself, or any account you expect to log into from a device that does not have your manager installed. For ordinary site logins where you only ever paste, leave the toggle off and accept the extra entropy.
If you're weighing options, SHA-512 Password Hash With Salt: What the Output Means covers this in detail.