Secure Password Generator Online: 2026 Best Practices

Secure Password Generator Online: 2026 Best Practices

Length, entropy, symbols: generate a strong password in your browser with Web Crypto, no network transit, and know what the tool does not guarantee.

01.10.2026
12 min read
Share this article:
Password
Security
tools-dev
Tutorial

A strong password is long, random and never reused

A weak password rarely fails for lack of symbols: it fails because a human chose it. FastMinify's online password generator draws every character at random with crypto.getRandomValues (Web Crypto) in your browser — never Math.random — and the generated values are neither sent nor stored. It controls length (8 to 128), four character sets, ambiguous-glyph exclusion and a count up to 50. It shows no strength meter, offers no passphrase mode and remembers nothing. This guide explains why length matters more than complexity, what each setting changes in bits, where the tool stops (no "at least one digit" guarantee), and how to store a password server-side afterwards with a slow hash rather than a fast one — the bcrypt tool helps you understand the parameters on fixtures. The page lives on the developer utilities hub, next to the UUID generator and the regex tester, and is reachable from the security tools hub.

Length from 8 to 128 characters, by slider or keyboard; 16 by default
Four character sets: a–z, A–Z, 0–9 and symbols. At least one must stay on, otherwise the tool shows an error
Fixed symbols: !@#$%^&*()-_=+[]{}|;:,.<>? — 26 characters, no space, no custom set
"Exclude ambiguous" (on by default) removes 0, O, o, I, l and 1 from the draw pool
Count from 1 to 50: the numbered list regenerates as soon as an option changes, with copy for the whole list or a single line
Web Crypto draw with rejection of values that would skew the distribution. Without crypto.getRandomValues, the tool shows an error instead of a weak fallback

Where the local generator is enough, and where to hand over

Fitting uses

A password or a test secret to produce quickly, without the value passing through a server.

An account password to file straight into a password manager: 16 characters, four classes, ambiguous excluded
A fixture or staging secret (test database, demo account), up to 50 at once
A password to dictate or retype from a screen: keep "Exclude ambiguous" on
A target that rejects some symbols: turn "Symbols" off and go to 20 characters or more
A set of values to test a validation policy (lengths 8, 12, 64 and 128)
What belongs elsewhere

Generating is only one link: server-side storage (the bcrypt tool), leak detection (the secrets scanner) and message authentication (the hash and HMAC guide) each have their own tools.

Keeping the password: a dedicated password manager. The tool saves nothing; reloading the page produces another list
Storing server-side: a slow, salted hash (bcrypt, Argon2). The bcrypt tool (cost 4 to 14, warning at 72 bytes) is for understanding and producing fixtures, not for building authentication
Checking a password was not already committed: scan the diff before committing, and rotate immediately if the secret is already pushed
Signing a webhook or authenticating a message: an HMAC with a secret key, not a password
Checking that a human-chosen password does not appear in a known breach: outside the tool's scope

Four mistakes that weaken a password, even a generated one

Stacking complexity rules on a short password

"One uppercase letter, one digit, one symbol" applied to eight characters gives a feeling of security without the substance. With the tool's default set (82 possible characters), 8 random characters are worth about 51 bits, 16 characters about 102 bits. A hand-built password like Spring2026! satisfies every rule and still contains almost no randomness: an attacker tries dictionary words, years and common substitutions first. NIST SP 800-63B (revision 4) points the same way: favor length, accept long passwords (at least 64 characters), and do not impose composition rules or periodic rotation without suspicion of compromise.

Believing a symbol tacked onto a dictionary word makes it safe
Staying at 8 characters because the form accepts it
Rotating the password every 90 days by incrementing a digit
Measuring strength by the number of character classes rather than by the amount of randomness
Generating on a page that sees the value

A generator is only safe if the value never leaves the device. Here the draw happens in your tab; a server-side generator, or a page whose publisher logs what it displays, would see the secret. This does not protect against a malicious browser extension, a synced clipboard or a screenshot. One detail specific to this tool: the very first paint of the page shows a list derived from a fixed seed (so server HTML and hydration match), replaced by a Web Crypto draw as soon as the script runs. Copy only once the page has loaded. After that the list stays in memory until you reload or press "Clear all": the tool keeps no history.

Copying a value before the page has finished loading
Pasting a password into a ticket, a chat or a shared screenshot
Letting a synced clipboard history keep the secret
Using a generator whose draw location you cannot verify
Expecting a composition rule the tool does not guarantee

The tool draws each character uniformly from the active set; it does not force "at least one digit, one symbol". With the default settings (16 characters, 82 possible, 8 of them digits), roughly one password in five contains no digit, and only about 80% of draws contain all four classes. If the form demands a class, do not type it by hand at the end of the line: scan the list (up to 50 lines) and take one that contains it. Choosing among conforming draws costs less than one bit of entropy. The symbol set is fixed (26 characters, no space) and some sites reject a few of them: turn "Symbols" off and make up for it with length.

Assuming a draw always contains an uppercase letter, a digit and a symbol
Appending "1!" by hand to a line to pass validation
Keeping symbols the target site rejects and going in circles on the error message
Forgetting that some systems cap the length
Confusing an identifier, a hash and a password

A UUID v4 carries 122 random bits, but the specification (RFC 9562) does not present it as a secret: see the UUID, ULID and Nanoid guide. A hash such as SHA-256 is fast by design, so poorly suited to storing a password — a graphics card tests billions per second; the hash and HMAC guide covers what it is for (integrity, signatures). Storing a password calls for a slow, salted hash (bcrypt, Argon2). The password generated here is the user's secret; what the server keeps is its slow hash. Mind bcrypt too: it only reads the first 72 bytes. The generator goes up to 128 characters, but beyond 72 ASCII characters the rest never enters the hash — the bcrypt tool shows a warning in that case.

Storing a password with MD5 or SHA-256, even salted
Treating a UUID as a secret when the specification does not promise it
Generating 100 characters and believing they all count in bcrypt
Leaving a plaintext password in logs or in a versioned .env file

Entropy: what length and character sets change in bits

The formula: length × log₂(set size)

For a uniform, independent draw — which is what the tool does, and not what a human-chosen password does — entropy is a direct calculation.

Formula: bits = length × log₂(set size). Each added character multiplies the search space by the size of the set.
Default setting (a–z, A–Z, 0–9, symbols, ambiguous excluded): 24 + 24 + 8 + 26 = 82 characters, about 6.36 bits per character. 8 characters ≈ 51 bits, 12 ≈ 76 bits, 16 ≈ 102 bits, 20 ≈ 127 bits.
Without excluding ambiguous glyphs: 88 characters, about 6.46 bits each — 16 characters ≈ 103 bits. Excluding ambiguous glyphs therefore costs only about 1.7 bits over 16 characters.
Letters and digits only (ambiguous excluded): 56 characters, about 5.81 bits each. 16 characters ≈ 93 bits; 18 characters ≈ 105 bits, already above 16 characters of the full set.
Lowercase only (ambiguous excluded): 24 characters, about 4.58 bits — 16 characters ≈ 73 bits. Digits only, exclusion off: 10 characters, 12 digits ≈ 40 bits, which is a code or a fixture fragment, not a password.
Stored random string or memorized passphrase

The tool only produces randomly drawn character strings. For a secret you have to remember, the logic is different.

The tool's random string: impossible to remember beyond a few characters, so it belongs in a password manager. 16 characters ≈ 102 bits.
Diceware-style passphrase: each word drawn from a list of 7,776 words adds about 12.9 bits; 6 words ≈ 77 bits. That only holds if the words are drawn at random (dice or a tool), not chosen for their meaning.
FastMinify does not generate passphrases: the length field counts characters, not words. For a password manager's master password, a dice-drawn phrase fits; for everything else, a stored random string.
Beyond roughly a hundred bits, adding more bits changes little in practice: the weak link becomes storage, reuse or phishing.
What the target imposes or caps

The right length also depends on what the receiving system accepts and actually checks.

NIST SP 800-63B (revision 4): favor length, accept at least 64 characters, impose no composition rules or periodic rotation; 15 characters minimum when the password is the only authentication factor.
bcrypt: only the first 72 bytes count. A 100-character ASCII password is verified on its first 72 only.
Some forms cap at 16, 20 or 32 characters or reject symbols: set the tool to what the target accepts, then win bits back by keeping all four classes.
A list meant for fixtures can run from 8 to 128 characters: 8, 12, 64 and 128 cover the usual bounds of a validation policy.

Generate, copy, clear: the walkthrough in the tool

Set, read the list, copy

The password generator has no "Generate" button: the list fills on load and regenerates on every option change.

1

Pick the length

Type a number from 8 to 128 or use the slider; the default is 16. A value out of bounds is brought back into the range.

2

Enable the sets you need

a–z, A–Z, 0–9 and Symbols are on by default. If you turn all four off, the tool shows "Enable at least one character set." and the list stays empty.

3

Get another list

Changing the count by one, toggling "Exclude ambiguous" or reloading the page produces a new draw. There is no regenerate button at constant settings.

4

Copy a line or the whole list

Each line has its own copy button; "Copy all" copies the list, one password per line. "Clear all" empties the list until the next option change.

What the tool does not do

A few limits to know before relying on it for a specific use.

No strength or entropy meter: use the formula in this guide
No passphrase mode, no "at least one of each class" rule
Fixed symbols (26): no custom set, no accented characters
Nothing is remembered: no history, the list disappears on reload
The share button sends the tool page, not the passwords on screen

The same draw in your own code

Node: a uniform draw with crypto.randomInt

The tool's default set (82 characters, ambiguous excluded) in a few lines. randomInt avoids modulo bias.

Basic example

import { randomInt } from 'node:crypto' const ALPHABET = 'abcdefghijkmnpqrstuvwxyz' + // without l, o 'ABCDEFGHJKLMNPQRSTUVWXYZ' + // without I, O '23456789' + // without 0, 1 '!@#$%^&*()-_=+[]{}|;:,.<>?' function password(length = 16) { let out = '' for (let i = 0; i < length; i++) { out += ALPHABET[randomInt(ALPHABET.length)] } return out } console.log(password(16)) // 16 characters out of 82 console.log((16 * Math.log2(ALPHABET.length)).toFixed(1)) // 101.7 bits
Browser: getRandomValues with rejection

To draw an index without bias, reject values above the largest multiple of the set size — which is what the tool does.

Basic example

function randomIndex(max) { // largest multiple of max below 2^32 const limit = Math.floor(0x100000000 / max) * max const buf = new Uint32Array(1) do { crypto.getRandomValues(buf) } while (buf[0] >= limit) return buf[0] % max } // a plain buf[0] % max slightly favors the first characters
Storing: a slow hash on the server

The generated password stays the user's secret; the server only keeps a bcrypt hash. The tool's cost ranges from 4 to 14 (10 by default).

Basic example

import bcrypt from 'bcryptjs' const hash = await bcrypt.hash(password, 12) // cost 12 const ok = await bcrypt.compare(candidate, hash) // true | false // bcrypt ignores everything after 72 bytes
FastMinify password-generator

No installation, nothing sent, four classes, 8 to 128 characters and up to 50 lines at a time. Trade-offs: no strength meter, no passphrase mode, no "at least one of each" guarantee and fixed symbols. Keep the page for a password to file straight into a password manager or for fixtures. For server-side storage, go through bcrypt or Argon2 in your own code; for a value to sign, through an HMAC with the hash generator.

Conclusion

A solid password is long, drawn at random by a sound generator and used once. The online password generator produces that draw in your browser with Web Crypto: 16 characters from all four classes are worth about 102 bits, far more than a 10-character "complex" password written by hand. Do not ask it for what it does not promise: no strength meter, no passphrase, no "at least one digit" guarantee. File the result in a password manager, hash it with bcrypt or Argon2 on the server, and do not mix up a UUID, a fast hash and a password. For what comes next, the developer utilities hub gathers the other generators, and the security tools hub the bcrypt, JWT and secret-scanning tools.

Length first: 16 characters at least for an account, more if the target accepts it
No per-class guarantee: if the form demands a digit, take another line from the list
Copy only once the page has loaded, paste into a password manager, then clear the list
bcrypt reads only 72 bytes: beyond that, extra characters protect nothing
Server storage: slow, salted hash (bcrypt, Argon2), never MD5 or SHA-256 alone
Share this article
Share this article: