Somewhere around 2020, during my WP Adminify years, I spent a very long Tuesday cleaning up a client's WordPress site that had been quietly serving pharma spam to Googlebot for three weeks. The entry point wasn't a plugin vulnerability. It wasn't a zero-day. It was the admin account — username admin, password Sumon1985@. The site owner's first name and birth year with an @ bolted on to satisfy the "special character" rule. A credential-stuffing bot walked straight in through wp-login.php. The access logs showed 11,000-odd login attempts over four days before one landed. Cleaning the injected code out of the theme files and the wp_options table took me the better part of a weekend.
That job changed how I think about passwords. Not because the attack was sophisticated — it was the opposite of sophisticated. It was a script hammering a login form with a wordlist, and a human-invented password sat exactly where the wordlist expected it to be. Humans are terrible at randomness. We think P@ssw0rd2024! is clever. Every cracking dictionary on earth has that pattern in its first few thousand entries, complete with the leetspeak substitutions and the year suffix.
I'll admit my own sins here too. For an embarrassing stretch of my Laravel days, I reused the same password across three staging servers because "they're just staging, nobody cares." Then one of those staging boxes ended up with a copy of production data on it for a debugging session, and I realized I'd been protecting real user records with a password I'd also typed into a shared TeamViewer session at some point. Nothing bad happened. That was luck, not competence. I stopped inventing passwords entirely after that.
So I built a password generator into toolz.dev, and it does the one thing that matters: it takes the human out of the loop. This guide covers how to use a password generator online properly, the entropy math that separates a strong password from a decorative one, and when a random string beats a passphrase — with actual numbers, not vibes.
TL;DR: Stop inventing passwords — humans are predictably bad at it. Use the toolz.dev Password Generator to create 16+ character random passwords with a cryptographically secure RNG, entirely in your browser. Nothing you generate ever leaves your device, and length matters far more than symbol gymnastics.
Key Features
Cryptographically Secure Randomness
This is the feature that matters most and the one nobody looks at. The generator uses the Web Crypto API's crypto.getRandomValues() — a cryptographically secure pseudo-random number generator (CSPRNG) seeded by your operating system's entropy pool — instead of JavaScript's Math.random(). That distinction isn't academic. Math.random() is built for animation timing and dice-roll demos; its output can be predicted if an attacker observes enough values, because the underlying algorithm (xorshift128+ in V8) was never designed to resist prediction. A CSPRNG is. When the whole point of a password is that nobody can guess it, the randomness source is the foundation everything else stands on. I've seen "password generator" snippets on Stack Overflow using Math.random() with hundreds of upvotes. Don't copy those.
Length Up to 128 Characters
The slider goes from short-and-risky to 128 characters of pure line noise. For anything a password manager will remember for you, I generate 24 to 32 characters and never think about it again. For systems with tight length caps — some banks still cap at 16 or 20, which tells you something about their backend — you dial it down to whatever the field accepts. Every character you add multiplies the attacker's work by the size of your character set. Going from 12 to 16 characters with a full charset adds roughly 26 bits of entropy, which is the difference between "expensive to crack" and "not happening before the sun burns out." Length is the cheapest security upgrade that exists.
Character Set Toggles
Four independent switches: uppercase, lowercase, digits, symbols. Mix and match per target system. This sounds trivial until you hit a legacy system that rejects & because someone's 2009-era sanitization layer chokes on it, or a Wi-Fi router firmware that silently truncates symbols. I once burned 40-odd minutes debugging a "wrong password" loop on a client's hosting panel before realizing their form stripped < and > on submit but not on account creation. Now I just toggle symbols off for cranky systems and add four characters of length to compensate. The entropy math works out to nearly the same place, and nothing breaks.
Exclude Ambiguous Characters
The Il1| and O0o problem. If you'll ever read a password off one screen and type it into another — a TV, a server console over IPMI, a router setup page, a colleague reading it aloud on a call — ambiguous glyphs are misery. Is that a capital I or a lowercase l or a pipe? Depends on the font, and the font always betrays you. The exclude-ambiguous toggle drops the usual suspects from the pool. You lose a small amount of entropy per character — easily recovered by adding one or two characters of length — and you gain never having that squinting-at-a-monospace-font argument again. For anything typed by hand, I flip this on without exception.
Live Strength and Entropy Feedback
As you adjust length and character sets, the strength meter updates instantly with a real entropy estimate — not the naive "has a symbol, must be strong" scoring that grades P@ssw0rd! as excellent. The meter reflects the actual keyspace: charset size raised to the length, expressed in bits. This turns the abstract math into something you can feel. Drag the length slider and watch the bits climb; toggle symbols off and see exactly what it costs. Once you've watched 16 random characters outscore 10 characters of forced complexity, the lesson sticks better than any policy document ever managed.
Bulk Generation
Need 20 passwords for a batch of service accounts, a fleet of routers, or seeding a team's credential rotation? Generate them in one pass and copy the lot. Each one is independently drawn from the CSPRNG — there's no sequence relationship between them, so knowing one tells you nothing about the next. I use this when provisioning: one password per .env secret, per database user, per queue worker credential, generated in a single sitting and pasted straight into the vault. It beats the alternative I've watched people do, which is generating one good password and then "varying" it by hand nine times. That's one password with nine costumes.
100% Client-Side — Nothing Ever Leaves Your Browser
Everything runs in your browser. The password is generated by JavaScript on your machine, displayed on your machine, and copied from your machine. No API call, no analytics event carrying the value, no server that could log it. Don't take my word for it — open DevTools, watch the Network tab, and hammer the generate button. Nothing fires. This is the same architecture principle behind every tool on toolz.dev, and I've written about why it's non-negotiable in my post on data privacy in online tools. A password generator online that round-trips your password through a server isn't a security tool. It's a collection point.
How to Use the Password Generator
Step 1: Open the Tool
Head to the Password Generator. No account, no signup wall, no cookie-consent labyrinth before you can click a button. It loads, it works. If you're on a machine you don't fully trust — hotel business center, borrowed laptop — remember the browser itself is your trust boundary: the tool won't transmit anything, but a keylogger on the host doesn't care whose JavaScript generated the string.
Step 2: Set Your Length
Default is a sane starting point, but drag it to at least 16 for anything that matters and 24+ for anything a password manager stores. Length is the single biggest lever you have. If the target system enforces a maximum, use every character it allows — there is no prize for leaving entropy on the table.
Step 3: Choose Character Sets
Leave all four sets on unless the target system objects. Toggle symbols off for legacy forms and firmware that mishandle them; flip on the exclude-ambiguous option if a human will ever transcribe the password by hand. Watch the strength meter as you toggle — it shows you exactly what each choice costs or buys in bits.
Step 4: Generate, Copy, Store
Click generate, click copy, paste it directly into your password manager — not into a text file, not into a Slack DM to yourself, not onto a sticky note that will outlive your civilization. Regenerate as many times as you like; each click is a fresh independent draw. If you need a batch, use bulk mode and store each one against its account immediately, before you forget which is which. I've made that mistake. Once.
What Makes a Password Actually Strong? The Entropy Math
Strength isn't about looking scrambled. It's about the size of the haystack an attacker has to search, and we measure that haystack in bits of entropy.
The formula is simple. If your password is length characters drawn uniformly at random from a character set of size charset, the number of possible passwords is charset^length, and the entropy in bits is:
entropy = log2(charset^length) = length × log2(charset)
Each additional bit doubles the search space. Worked examples:
- 12 lowercase letters: charset 26, log2(26) ≈ 4.70, so 12 × 4.70 ≈ 56 bits. Roughly 7.2 × 10^16 possibilities. Uncomfortable against modern GPU rigs cracking fast hashes.
- 16 characters, full charset (26 + 26 + 10 + ~10 symbols ≈ 94, but call it 95 printable ASCII): log2(94) ≈ 6.55, so 16 × 6.55 ≈ 105 bits. That's about 3.7 × 10^31 possibilities — half a quintillion times the 56-bit space.
- 24 characters, full charset: ≈ 157 bits. At that point the limiting factor is the service's hashing, not your password.
Notice what the formula rewards: length multiplies, complexity only nudges the log term. Going from lowercase-only to full charset lifts log2(charset) from 4.70 to 6.55 — nice, about 39% more bits per character. But doubling the length doubles the bits outright. This is why a 20-character lowercase password (94 bits) beats a 12-character everything-soup password (79 bits). Length wins. I'll die on this hill.
One crucial caveat: the formula only holds if characters are drawn uniformly at random. A human-picked password has far less entropy than its length suggests, because humans pick from a tiny, predictable subset — dictionary words, keyboard walks, dates, names. Crackers don't brute-force the full keyspace; they walk probability-ordered wordlists with mangling rules. Sumon1985@ isn't a 10-character search problem. It's a first-name-plus-year search problem, and that space is minuscule.
Uniform randomness is where the RNG matters. Here's the wrong way and the right way in JavaScript:
// WRONG — predictable PRNG, never for secrets
const bad = chars[Math.floor(Math.random() * chars.length)];
// RIGHT — CSPRNG via Web Crypto
const buf = new Uint32Array(1);
crypto.getRandomValues(buf);
const good = chars[buf[0] % chars.length];
Math.random() is a statistical PRNG: fine for shuffling a playlist, catastrophic for secrets, because its internal state can be recovered from observed outputs. crypto.getRandomValues() pulls from the OS entropy pool and is designed to be unpredictable even to an observer who sees other outputs.
Even the "right" example above has a subtle flaw worth knowing: modulo bias. If your charset size doesn't evenly divide 2^32, buf[0] % chars.length makes low-index characters slightly more likely. For a 94-character set the bias is tiny, but a careful implementation uses rejection sampling — discard values above the largest multiple of the charset size and draw again — so every character is exactly equally likely. It's a two-line fix, and it's the kind of detail that separates a real generator from a copy-pasted snippet.
Finally, the standards agree with the math. NIST SP 800-63B, the US federal digital identity guideline, says verifiers should favor length over composition rules (those "one uppercase, one symbol" requirements demonstrably push users toward predictable patterns), should not force periodic password rotation without evidence of compromise, and should screen new passwords against lists of known-breached passwords. The OWASP Authentication Cheat Sheet points the same direction: support long passwords, allow all printable characters including spaces, check against breach corpora, and pair passwords with MFA and rate limiting rather than complexity theater. When the standards bodies and the arithmetic both say "make it long and random," the debate is over.
Common Use Cases
New Service Signups
Every new account gets a fresh, unique random password — that's the whole discipline in one sentence. Credential stuffing, the attack that got my client's WordPress site, only works because people reuse passwords: a breach at some forgotten forum becomes a key to your email. If every signup gets its own 20+ character random string from the generator, a breach anywhere is contained there. The workflow takes ten seconds: generate on toolz.dev/tools/password-generator, paste into the signup form, save to the password manager. The password's job is to be unmemorable. That used to feel like a bug to me. It's the feature — anything you can remember, a wordlist can predict.
WordPress Admin and Database Credentials
This one's personal. After that pharma-spam cleanup, my WordPress hardening checklist starts with credentials, not plugins: a random 24+ character admin password, a different random password for every additional admin user, a random DB_PASSWORD in wp-config.php, and random salts. The database password especially — I've audited sites where it was the site name plus "123", sitting in a world-readable backup of wp-config.php. WordPress sites get hit by dumb, relentless automation; wp-login.php and xmlrpc.php see login attempts within hours of a site going live. Dumb automation is defeated by exactly one thing: passwords that aren't in any wordlist. Random strings, by construction, aren't.
API Keys, Secrets, and .env Files
When I'm scaffolding a Laravel or Express project and need a webhook signing secret, a cron endpoint token, or a one-off shared secret between two services, I generate a long random string — 32 to 64 characters, sometimes symbols off if it'll live in a URL — and drop it into .env. For identifiers I need to be unique but not secret, that's a different tool: the UUID Generator covers that job. And if you're checking what's actually inside a token a service handed you, the JWT Decoder will unpack it client-side. More on that whole workflow in my coding tools guide. The rule I follow: secrets get generated, never invented, and never reused between environments. Ask me how I learned that. (Staging servers. Three of them.)
Shared Team Accounts and Password Managers
Some accounts genuinely have to be shared — the company Twitter, a registrar login, that one SaaS that charges per seat like it's printing money. Shared credentials are where human-invented passwords get worst, because they optimize for "easy to tell a colleague over a call." The fix is a random generated password stored in a shared password-manager vault, so nobody ever needs to speak, type, or remember it. When someone leaves the team, regenerate and update the vault entry — a two-minute chore instead of an awkward security incident. Bulk generation helps here: rotate every shared credential in one sitting instead of promising yourself you'll get to the rest next sprint. You won't. I never did.
Wi-Fi Passphrases
Router setup is the classic exclude-ambiguous scenario: you'll type this password on phone keyboards, smart TVs with a directional-pad keyboard, and a guest's laptop while they hover over your shoulder. I generate 20+ characters, symbols off, ambiguous characters excluded — letters and digits only. Still vastly stronger than the street-name-plus-year most home networks run, because WPA2 handshakes can be captured and cracked offline where attempt rates are enormous. The entropy math doesn't care that it's "just Wi-Fi." A letters-and-digits charset of 62 still gives log2(62) ≈ 5.95 bits per character; 20 characters is ~119 bits. Nobody is brute-forcing that, and your guests can still type it in under a minute.
Random Passwords vs Passphrases vs Human Patterns
Three ways people make passwords. Only two of them are defensible.
| Approach | Entropy at typical length | Memorability | Typing on mobile | Best for |
|---|---|---|---|---|
| Random string (generator, 16-24 chars, full charset) | ~105-157 bits | Effectively zero — that's fine | Painful, but you paste from a manager | Everything a password manager stores: accounts, DB creds, API secrets |
| Diceware passphrase (5-6 random words) | ~64-77 bits (12.9 bits/word from a 7,776-word list) | Genuinely good | Easy — real words, few symbols | The handful you must memorize: manager master password, OS login, disk encryption |
Human-invented pattern (Name+Year!, keyboard walks) |
Looks like 50+ bits, behaves like 20-30 against wordlists | Good, deceptively | Easy | Nothing. Retire these. |
My stance: random strings for everything your password manager stores, a diceware passphrase for the two or three secrets that have to live in your head, and human-invented patterns for nothing at all. The passphrase-versus-random debate mostly evaporates once you notice they serve different jobs. A 24-character random string at 157 bits is mathematically stronger than a 6-word passphrase at 77 bits — but you'll never type the random one from memory, and you'll never forget the passphrase. So use each where it wins. The only rule with passphrases: the words must be randomly selected from a wordlist (dice or CSPRNG), not chosen by you. correct-horse-battery-staple chosen because you read the comic has near-zero entropy. Four words rolled with actual dice have 51.7 bits, exactly as advertised.
Frequently Asked Questions
How long should a password be in 2026?
At least 16 characters for anything that matters, and 24 or more when a password manager is doing the remembering. NIST SP 800-63B emphasizes length over composition rules, and the entropy math backs it up: a 16-character full-charset random password carries roughly 105 bits, comfortably beyond practical brute force. If a site caps you shorter, use every character it allows and enable two-factor authentication there.
Are online password generators safe to use?
They're safe if — and only if — they run entirely client-side with a cryptographically secure RNG. The toolz.dev generator creates passwords in your browser with the Web Crypto API and never transmits them; you can verify by watching the Network tab while generating, where no request fires. Avoid any generator that produces passwords on a server, because you'd be trusting a stranger's logs with your secrets.
Is a passphrase better than a random password?
They win at different jobs. A 24-character random string is mathematically stronger, but you can't memorize it — perfect for password-manager storage. A 5-6 word diceware passphrase carries 64-77 bits and is genuinely memorable — perfect for the master password itself, your OS login, and disk encryption. Use random strings for everything stored, a passphrase for the few secrets that must live in your head.
How does the generator create randomness?
It calls crypto.getRandomValues() from the Web Crypto API, a cryptographically secure pseudo-random number generator seeded by your operating system's entropy pool. Unlike Math.random(), its output can't be predicted from previously observed values, which is the property a password fundamentally depends on. Careful implementations also avoid modulo bias, so every character in your chosen set is exactly equally likely.
Should I change my passwords every 90 days?
No — not on a schedule. NIST SP 800-63B specifically advises against mandatory periodic rotation, because forced changes push people toward incremental patterns like Password1, Password2 that attackers try first. Change a password when there's an actual reason: the service was breached, you accidentally exposed it, you typed it on an untrusted machine, or someone with shared access leaves the team.
Do I really need symbols in my password?
Not as much as the signup forms insist. Symbols raise per-character entropy from about 5.95 bits (letters plus digits) to about 6.55 bits (full printable set) — helpful, but two extra characters of length buys more than symbols do. If a legacy system or router mishandles symbols, turn them off and add length. A 20-character alphanumeric password beats a 14-character symbol-laden one every time.
Can a password generated in my browser be intercepted?
Not by the tool itself — a client-side generator makes no network request containing the password, so there is nothing in transit to intercept. The realistic risks live on your own device: malware, keyloggers, or a compromised browser extension with page access. Keep your machine and extensions clean, paste generated passwords straight into a password manager, and avoid generating credentials on computers you don't control.
What's the strongest password I can make?
Practically: the longest fully random string the target system accepts, generated with a CSPRNG using all four character sets. At 32 characters of full charset you're past 200 bits, where the password stops being the weakest link entirely — the service's hashing, session handling, and your device security matter more. Chasing bits beyond that is decoration; spend the effort enabling MFA and unique passwords everywhere instead.
Is it safe to let my browser save my passwords?
Safer than reusing passwords, less capable than a dedicated manager. Chrome, Firefox, and Safari encrypt saved credentials behind your OS login and sync them over encrypted channels, which comfortably beats a spreadsheet or a repeated password. A dedicated manager adds the things browsers skip: cross-browser access, secure sharing with a team, breach monitoring, and storage for non-password secrets like recovery codes and API keys.
What are the most common passwords attackers try first?
Leaked-password lists, not brute force. Cracking tools open with the greatest hits of every breach — 123456, password, qwerty — then keyboard walks, years, pet names, and dictionary words with a tacked-on "123!" or "@" swap. Every human-invented pattern is already in those wordlists, which is exactly why a randomly generated string, which follows no pattern at all, sidesteps the entire first wave of any attack.
Generate One Now — Then Never Think About It Again
The best password workflow is boring. Open the Password Generator, drag the length up, generate, save to your manager, move on with your life. No cleverness, no mnemonic systems, no birth years wearing an @ as a disguise. Every password unique, every one random, none of them living in your head. The Tuesday I spent scraping pharma spam out of a client's theme files was entirely preventable by exactly this ten-second habit.
If you're securing a whole stack, the neighbors are one tab away: the Hash Generator for checksums and integrity verification, the UUID Generator for identifiers that need uniqueness rather than secrecy, and the JWT Decoder for inspecting tokens without pasting them into some random site's backend. All client-side, same as the generator — the reasoning behind that architecture is in the data privacy post, and the broader toolkit tour lives in the coding tools guide.
One habit, ten seconds, real math behind it. That's the whole pitch.
