Skip to main content
Tools Harbor

Secure Password Generator

Free, strong password generator — any length from 4 to 64 characters, fully offline.

Strength
Weak · 0 bits
Quick length
Character sets

This tool builds a password from crypto.getRandomValues() — the Web Crypto API’s cryptographically secure random source — rather than Math.random(), which is fast but predictable and unfit for generating secrets. Pick a length from 4 to 64 characters, choose which character classes to draw from, and a password appears immediately; Regenerate makes a new one with the same settings, Copy puts it on your clipboard. Nothing about the password, or the settings behind it, is ever sent anywhere — it exists only in this tab until you copy it or close the page.

Quick reference

SettingDetail
LengthSlider, 4–64 characters, default 20. Quick-pick buttons for 8, 10, 12, 14, 16, 20, 32
Character setslowercase (a–z), UPPERCASE (A–Z), digits (0–9), symbols — each toggled independently, all four on by default
Symbol set!@#$%^&*()-_=+[]{};:,.?/ — 24 fixed characters, not user-editable
Exclude ambiguous (default on)Drops 0, 1, O, I and l — the five characters in the sets above that are easy to misread — taking the full alphabet from 86 characters to 81
Randomness sourcecrypto.getRandomValues() — a genuine CSPRNG, not Math.random()
Strength meterWeak/Fair/Strong/Excellent label plus a bit estimate, both computed as length × log2(alphabet size) from the alphabet the password was drawn from

What actually makes a password strong?

Strength reduces to one number: entropy, in bits — how many yes/no guesses a perfect attacker needs, on average, to land on your exact password by brute force. The formula is bits = length × log2(alphabet size), and the two factors don’t pull equal weight.

Take this tool’s own defaults: all four classes on, ambiguous characters excluded, leaving an 81-character alphabet (25 lowercase, 24 uppercase, 8 digits, all 24 symbols). log2(81) ≈ 6.34 bits per character, so the default length of 20 gives roughly 127 bits — far past anything a brute-force search will ever exhaust. Turn symbols off and you’re down to a 57-character alphabet (letters and digits only); log2(57) ≈ 5.83, so the same 20 characters give about 117 bits — still enormous, because length carried the weight. Strip it down to lowercase only, 25 characters, and 20 characters still comes to log2(25) × 20 ≈ 92.9 bits, purely on length.

That’s the practical rule: adding a character class buys a few fixed bits per character; adding one more character buys the same multiplicative jump no matter which alphabet you’re in. A longer password from a small alphabet almost always beats a short one from a large alphabet.

None of this applies to how a site stores what you send it, which is a separate question entirely. A password should never sit in a database as plain text or as the output of a fast general-purpose digest — the hash generator on this site computes MD5, SHA-1 and the SHA-2 family, all built for speed and file-integrity checks, which is precisely the wrong property for password storage; a stolen fast hash can be brute-forced offline in the time it takes a stolen slow one (bcrypt, scrypt, Argon2) to resist a single attempt. That’s a property of the site you’re signing up for, not of the password you generate — but it’s worth knowing which side of that line a given hash sits on.

How long should a password be?

Longer than most sites enforce. NIST’s current guidance (SP 800-63B) sets an 8-character floor for user-chosen passwords and explicitly discourages two things people expect from a “strong password” policy: forced periodic rotation, which doesn’t stop a password from being reused before rotation catches it and nudges people toward predictable increments like Summer2025, Summer2026; and mandatory composition rules like “must include a symbol,” which narrow the practical choices people actually make — @ for a, ! at the end — more than they widen an attacker’s real search space.

For a generated password you’re never going to memorize, there’s no reason to hover near that 8-character floor. Treat 4 through 10 on this tool’s slider as a testing range, not a real setting. A reasonable ladder: 12 for a low-stakes account, 16 for anything that matters, 20 or more — the tool’s default — for your password manager’s own master password or your primary email, since both act as recovery paths into everything else. If a site enforces a maximum below what you’d pick, generate exactly at that maximum; there’s no reason to leave length unused.

Not every random string this tool is well-suited to producing is actually a password, either. A unique key for a database row or a resource ID in a URL doesn’t need to be memorable or entered by a human at all — a fixed-format identifier is the more legible shape there. The UUID generator produces the standard 36-character version-4 UUID via crypto.randomUUID(), immediately recognizable as an identifier rather than a credential, carrying about 122 bits of randomness regardless of the length you’d otherwise choose.

Passphrases vs random strings

A passphrase reaches the same entropy target a different way: instead of drawing single characters from a wide alphabet, you string together words from a large, fixed list, and the entropy comes from the list’s size and the word count, not from character variety. Four words picked at random from a 7,776-word list — the classic Diceware size, since 7,776 = 6⁵ — give log2(7776) × 4 ≈ 51.7 bits: noticeably less than a 16-character random string from this tool. Six words closes most of that gap, at roughly 77.5 bits.

This tool doesn’t build word-based passphrases; every character in its output is drawn independently from the sets you’ve checked, so the result has no pronounceable structure and isn’t meant to be memorized. That’s exactly right for a password manager vault entry you’ll never type by hand. It’s the wrong shape for the one credential you genuinely must recall from memory — a device passcode, or the manager’s own master password on a brand-new device — where a phrase you can actually retrieve reliably beats a random string you’ll mistype at the worst possible moment.

Common mistakes

Reusing one generated password everywhere. A single strong password reused across ten accounts turns one breach into ten, because leaked credentials get tested against other sites within hours. Generate a fresh one per site; that’s the job a password manager exists to make painless.

Assuming Base64 hides anything. Base64 is a reversible text encoding, not encryption — decode any string with the Base64 encoder/decoder in one click, no key required. A password stored “encoded” in a config file or script is exactly as exposed as one stored in plain text.

Not checking a site’s own length cap first. Some signup forms silently truncate past a hidden limit — you copy 32 characters, the field keeps 20, and the password saved in your manager no longer matches what the site accepted. Generate at a length you’re confident won’t get cut, or confirm you can log back in before closing the tab.

Leaving a generated password sitting in the clipboard. Clipboard contents are readable by whatever you switch to next, and some clipboard-history tools save everything indefinitely. Paste it where it belongs, then immediately copy something else over it.

Bolting a symbol onto a memorized word. Summer2026! looks complex but sits in a tiny, well-mapped corner of password space — cracking dictionaries already include the common substitutions layered onto ordinary words. A short list of predictable tweaks doesn’t add meaningful entropy; length does.

Privacy

Most privacy sections on this site are about protecting data you already had before a tool touched it. A generated password is the opposite case: the secret doesn’t exist until the moment of generation, so that moment is the only place it can leak, and it’s exactly why this tool runs the whole process locally. crypto.getRandomValues() asks your own device’s operating system for random bytes, and the string built from them never leaves the tab — there’s no fetch, no form submission, nothing to intercept.

Compare that to any password a service hands you instead of one you make yourself: a temporary password emailed after signup, a reset flow’s auto-filled replacement, a default credential printed on a router’s label. Each of those was generated somewhere you don’t control, which means some other system — a mail server, an app backend, a manufacturing line — held that exact string before you ever saw it. A JWT makes the point sharply: it’s a credential an authentication server generated, signed, and only then sent to you — decode one with the JWT decoder and the payload is exactly what that server chose to put there. There was never a moment that credential existed only for you. A password this generator produces is the rarer kind of secret that can actually claim that.

That guarantee ends exactly where your next action begins. Handing a device your Wi-Fi password via a QR code — a real use for the QR code generator, whose own placeholder text shows the WIFI:S:name;T:WPA;P:pass;; format — is private only because that tool also draws the code on a canvas locally. Screenshot the result into a cloud-backed photo library, and the password is traveling again, just in a different shape.

Frequently asked questions

How many bits of entropy does this generator actually produce?
It depends on your settings, but you can compute it yourself: bits = length × log2(alphabet size). With every character set on and ambiguous characters excluded (the defaults), the alphabet is 81 characters, so log2(81) ≈ 6.34 bits per character — a 20-character password works out to about 127 bits, and a 12-character one to about 76 bits.
Does excluding ambiguous characters weaken the password?
Only slightly. Excluding 0, 1, O, I and l drops the usable alphabet from 86 characters to 81, which costs about 0.09 bits per character — under 2 bits total even at 20 characters. If you plan to read the password aloud or type it by hand, that trade is almost always worth making.
Is crypto.getRandomValues() actually more secure than Math.random()?
Yes. Math.random()'s underlying algorithm isn't designed to resist prediction — enough observed outputs can let someone reconstruct its internal state and predict the rest, which is exactly the property you don't want in something generating secrets. crypto.getRandomValues(), the function this tool actually calls, draws from your operating system's cryptographically secure random source, the same category used to generate encryption keys.
Should I still use a password manager if I generate a strong password here?
Yes — a generator and a manager solve different halves of the same problem. This tool makes one strong, unique string; a manager is what lets you have a different one for every account without memorizing any of them. There's also no history here: nothing survives a regenerate or a page close, so save the password into a manager before you do either.
What exactly does the on-screen bit estimate measure?
The entropy of the draw that produced the password: length × log2(alphabet size), using the alphabet actually in force when you pressed Regenerate — so turning symbols off, or leaving ambiguous characters excluded, is reflected in the number. It is not a guess based on which characters happen to have landed in the result. That distinction matters: a random 20-character password can contain no digit purely by chance, and scoring it by inspection would quietly mark it weaker than the draw that made it. Change a setting without regenerating and the figure stays with the password on screen, which is the one it describes.