How to Generate Strong Passwords Safely

Length and entropy

Password strength is mostly about how hard the password is to guess. Long random passwords usually beat short complex-looking passwords because length increases the search space dramatically.

A 20-character random password from a broad character set is suitable for many everyday account workflows, provided it is unique and stored safely.

Randomness matters

Do not build security-sensitive passwords with predictable patterns, dates, keyboard walks, or ordinary pseudo-random helpers. Browser implementations should use cryptographic randomness such as crypto.getRandomValues.

Character sets and usability

Uppercase, lowercase, numbers, and symbols can all add search space. Usability still matters: if a password must be typed manually, avoiding ambiguous characters such as O/0 or l/1 can reduce mistakes.

Use a password manager

Random passwords are strongest when they are unique per account. A password manager makes that practical by storing long values you should not try to memorize.

• Do not reuse passwords across services.
• Copy generated passwords into a trusted password manager.
• Prefer multi-factor authentication for important accounts.
• Do not store generated passwords in screenshots, chat logs, or tickets.

Generation policy

Generator QA checks

• Requested length and enabled classes are always respected.
• Disabled and ambiguous characters never appear when excluded.
• Selection avoids modulo bias and guarantees required-class inclusion.
• Regeneration produces a different value.
• Passwords do not appear in network requests, metadata, URL state, storage, or logs.

Length, alphabet, and unbiased selection

A generator chooses characters from an enabled alphabet using cryptographically secure random bytes. Mapping a byte with a simple modulo operation can favor some characters when 256 is not divisible by the alphabet size. Rejection sampling avoids that bias by discarding values outside the largest evenly divisible range.

When a policy requires uppercase, lowercase, digits, or symbols, guarantee at least one character from each selected class and securely shuffle their positions. Appending required characters in a fixed order creates a predictable structure even when the characters themselves are random.

The lifecycle matters after generation

A strong generated value can still be exposed through screen sharing, clipboard history, chat, shell history, browser storage, or password reuse. Copy it directly into a trusted password manager and clear temporary copies. Do not place it in a URL, because URLs frequently reach history, referrer, proxy, and analytics logs.

Composition rules vary across services. Longer random passwords usually provide more value than forcing frequent changes or obscure symbol rules. Follow the account's accepted character set without weakening the value to make it memorable; a password manager removes the need to memorize unique random credentials.

Generator acceptance tests

• Minimum, default, and maximum length produce exactly the requested number of characters.
• Every enabled required class appears and every disabled class is absent.
• Ambiguous characters never appear when exclusion is selected.
• No character is statistically favored by byte-to-index mapping.
• Reload clears the value and URL, storage, metadata, logs, and network requests never contain it.
• Regeneration replaces the value with a different cryptographically generated result.

References

• NIST SP 800-63B-4: Authentication and Authenticator Management
• OWASP Authentication Cheat Sheet
• MDN Crypto.getRandomValues

FAQ

Related guides