Password Generator

Build passwords around the threat, not a composition checklist

A password has one job: remain impractical to guess. Length and unpredictable selection matter more than decorative complexity rules. A 20-character value selected independently from a large alphabet is usually harder to search than a short value containing one uppercase letter, one digit, and one symbol in predictable positions. Reusing that strong value on another site still defeats the purpose, because one breach can expose both accounts.

This random password generator provides lengths from 4 through 128, a quantity from 1 through 50, and separate uppercase, lowercase, number, and symbol pools. It also has an ambiguity filter, reveal or hide display, regeneration, individual copy, and Copy All. At least one character type remains selected. When several types are enabled, generation attempts to include a character from every selected pool.

There is an essential implementation limitation: this page currently selects and shuffles characters with JavaScript Math.random(). That is useful for examples, fixtures, throwaway local services, and evaluating password-policy constraints, but Math.random() is not a cryptographically secure pseudorandom number generator. Do not treat output from this browser demo as a production administrator password, recovery code, encryption passphrase, API secret, or any credential protecting real data. For production, use a reputable password manager or code backed by crypto.getRandomValues(), Node.js crypto.randomInt(), or the operating system CSPRNG.

A practical pass through the controls

Set Length before worrying about symbols. Sixteen characters may suit a typical generated website credential; 20 to 24 leaves more margin, especially where the allowed alphabet is narrow. Four characters exists for testing restrictive forms, not for securing an account. A service’s maximum length should be treated carefully: unexplained truncation can make two apparently different passwords equivalent.

Enable the character classes accepted by the destination:

• Uppercase (A-Z) and Lowercase (a-z) supply Latin ASCII letters.
• Numbers (0-9) add decimal digits.
• Symbols add punctuation including !@#$%^&*()_+-=[]{}|;:',./<>?.
• Avoid Ambiguous removes lookalikes including uppercase I and O, lowercase i, l, and o, digits 0, 1, 2, and 5, plus the vertical bar.

The ambiguity option is sensible for a credential that someone must read from paper, dictate, or enter on a television. It slightly shrinks the alphabet, so compensate with length. It is generally unnecessary for values moved only through a password manager.

Choose Quantity to create test records or compare form behavior. Changing any control regenerates the list automatically; Regenerate requests another batch with unchanged settings. Hide applies a visual blur to the displayed strings, while Reveal removes it. This is shoulder-surfing protection, not secret storage: the values remain in the page and can still be copied. Clicking a row copies one value; Copy All writes newline-separated values to the clipboard. Clipboard managers, browser extensions, screen sharing, and synced clipboards may retain them.

Reading the strength meter honestly

The meter examines the first generated password. It infers an alphabet size from character classes observed in that value, then estimates entropy as length × log2(pool size). For example, an ideal 16-character selection from 62 letters and digits has an upper-bound estimate near 16 × log2(62), or 95 bits.

That formula assumes uniformly random, independent choices. It badly overstates a human-created string such as Summer2026!Summer, whose structure is guessable despite its classes and length. It also does not model leaks, password reuse, service rate limits, or this component’s Math.random() limitation. Read Very Weak through Very Strong as a configuration hint, not a security proof or crack-time promise.

Composition guarantees also change the exact distribution. Requiring at least one member of every selected class means the output is not simply an unconstrained draw from one combined alphabet. That distinction rarely matters for form testing, but rigorous security estimates must describe the actual generator.

Concrete development scenarios

Suppose a signup form requires 12 to 64 characters, one character from each class, and rejects whitespace. Set length 16, enable all four pools, generate 50, and submit the batch in an automated staging test. Verify every accepted value can authenticate, survives database and transport boundaries unchanged, and can be reset. Include separate hand-written edge cases because random sampling does not guarantee coverage: exactly 12 characters, exactly 64, apostrophes, backslashes if the product permits them, and leading or trailing punctuation.

For a temporary demo account where symbols break a legacy shell script, select uppercase, lowercase, and numbers, then use a longer value. Do not silently strip punctuation from an already generated password: transformation changes the selected distribution and may create an empty or duplicated result. Generate against the correct alphabet instead.

For a human-transcribed Wi-Fi lab credential, turn on Avoid Ambiguous and choose 20 or more characters. A grouped passphrase may be easier to communicate, but this tool generates character strings rather than dictionary-word passphrases. Hyphens added afterward count as literal password characters only if the receiving system preserves them.

Passwords are not password hashes

Generation and storage solve different problems. An application receives a password over a protected channel and stores a slow, salted password hash using Argon2id, scrypt, bcrypt, or PBKDF2 with parameters calibrated for its environment. It does not store a SHA-256 digest, reversible encryption, Base64 text, or plaintext. Base64 is encoding; it offers no secrecy. Encryption is reversible with a key; ordinary password verification should not need recovery of the original.

A unique salt prevents equal passwords from producing equal stored records and defeats precomputed rainbow tables. A server-side pepper can add defense in depth when held outside the database, but it does not replace salts or a password-hashing function. MFA, rate limiting, breached-password checks, secure reset flows, and session protection still matter.

Never paste a real existing password into an online password generator to “strengthen” or inspect it. A generator needs no old secret. Prefer creating and saving a new credential directly inside a trusted manager, and rotate it only when compromised, shared improperly, or required by a concrete policy.

Mistakes that weaken otherwise good output

Editing 7v!G... into a memorable word discards randomness in a way the meter cannot assess. Saving 50 candidates in a ticket, chat, test log, or source repository exposes all of them. Using one generated value for database, cloud, and admin access creates a shared failure domain. Emailing a password separately from its username is not automatically safe if both messages reach the same compromised mailbox.

Client-side form rules cause another class of failure. Some systems normalize Unicode, trim spaces, interpret quotes, or mishandle symbols. This tool uses an ASCII alphabet, but transport layers can still alter punctuation through shell expansion, URLs, YAML, or SQL assembled incorrectly. Pass credentials as data through parameterized APIs and secret stores, never by string concatenation.

Production automation should generate secrets at deployment time with a CSPRNG, put them directly into a secret manager, grant narrowly scoped access, and avoid printing them. Test automation should use clearly non-production credentials and redact failure output.

FAQ

What settings should I use for a secure random password?

For a compatible modern service, a unique manager-generated value of at least 16 characters with a broad alphabet is a reasonable baseline. Higher-value accounts can use more length. This page’s settings illustrate that configuration, but its Math.random() output is for development and demonstration rather than production secrets.

Are symbols always necessary?

No. If choices are truly uniform, adding symbols expands the alphabet, but adding length can provide equal or greater search space. Follow the service’s accepted-character policy and avoid predictable substitutions such as a to @ in human passwords.

Does hiding a password erase it?

No. Hide only blurs the rendered text. The value remains in component state, and copying it places it on the system clipboard.

Why did the list change when I adjusted quantity?

Length, quantity, and option changes trigger a fresh generation. Copy anything needed for a non-sensitive test before changing controls.

Can I use Copy All to seed users?

Only for isolated development fixtures. Do not distribute real user passwords or retain plaintext credentials. A production onboarding flow should use invitations or one-time setup links and hash the password on submission.