A generated password is useful only if it is unpredictable, accepted by the service and stored where you can retrieve it. A long random value lost after closing a tab is not a successful account setup. Build password generation around a password-manager workflow and a verified recovery path.
Choose a unique password for each account. Reuse allows a compromise at one service to threaten others, regardless of how impressive the password originally looked. Generation, storage, account recovery and multifactor protection solve different parts of the problem.
Use a suitable source of randomness
The password generator uses the browser's cryptographic random facility and a defined character alphabet. Its generation logic uses rejection sampling to avoid bias from mapping random bytes unevenly into the alphabet.
Math.random is not a suitable substitute for security-sensitive secret generation. Neither is choosing characters according to a memorable keyboard pattern. The entropy calculation for a password assumes independent, appropriately uniform choices; it does not apply to a human imitation of randomness.
The tool keeps generated secrets separate from ordinary report exports and printed findings. That reduces accidental inclusion in diagnostic files, but you still need to save the password deliberately in your intended password manager or account workflow.
Understand what a length calculation assumes
If each character is chosen uniformly from an alphabet of size A, a length-L password has L multiplied by log base two of A bits of selection entropy. For an alphabet of 64 equally likely characters, each character contributes six bits. Sixteen characters give 96 bits under those assumptions.
Twenty characters from that same alphabet give 120 bits. These numbers describe the generation space, not a universal time-to-crack promise. Attack speed depends on how a service stores passwords, whether guesses are online or offline and what an attacker knows.
Service restrictions can change the distribution. A rule requiring at least one character from each category may need a carefully designed generation strategy. Do not report the simple formula as exact if the actual algorithm uses a different constrained distribution.
| Decision | Purpose | Practical check |
|---|---|---|
| Unique value per account | Limit cross-service reuse risk | Save under the correct site entry |
| Cryptographic generation | Avoid predictable patterns | Use a trusted generator |
| Sufficient length | Provide a large search space | Respect the service's supported limits |
| Password manager storage | Make strong values usable | Verify the saved entry with a fresh login |
| Recovery planning | Survive device or account loss | Retain recovery methods securely |
| Multifactor or passkey support | Add protection beyond a reusable password | Test the recovery path too |
Generate, save and verify in that order
Open the service through its known official address and prepare the password-manager entry. Generate a password that fits the site's rules, save it in the correct entry and submit it through the normal account form. Avoid leaving the only copy in a clipboard or temporary note.
After the change, verify a fresh login using the saved entry. Keep the existing authenticated session available until you know the new credential works, where the service's flow permits that. A successful password-change banner does not prove the manager saved the intended value.
Check that the entry is associated with the correct domain. Password-manager autofill can help users notice a lookalike site when the expected credential is not offered, but the user still needs to follow the manager's security guidance and verify unusual prompts.
Handle service limits without creating a predictable pattern
Some services reject particular symbols, impose a maximum length or mishandle pasted input. Generate a fresh password from a supported alphabet rather than editing the same familiar base password for every site. Keep each account independent.
If a service silently truncates passwords, that is an implementation concern worth investigating through its support process. Do not assume a visually long input is fully used. For systems you build, support appropriate password lengths and avoid transformations that surprise users.
Do not remove all symbols merely because one unsupported character caused a problem if the service's documented rules allow a suitable set. Conversely, symbols are not magic: a longer uniformly random password from a smaller accepted alphabet can provide a large search space.
Move a reused account to an independent password
Suppose an old password is reused on email, shopping and a work tool. Start with the account whose compromise would unlock the others, often email. Confirm recovery access and create a new unique entry through the password manager.
Change the password, verify login and review active sessions where the service supports it. Then repeat for the other accounts with different generated values. Keep a checklist of account names and completion status without recording the passwords themselves in the checklist.
Remove or update stale saved credentials on other devices. A phone repeatedly submitting the old password can create confusing alerts or lockouts. Check applications that use separate app passwords or tokens rather than assuming the main password change updates every integration.
Finish by reviewing recovery addresses and multifactor methods. A strong password does not help if an attacker already controls an easier recovery route. Keep the recovery process usable for you and resistant to unauthorised changes.
Treat copying as a temporary transfer
Clipboard contents can be retained by clipboard managers, synced across devices or read by applications according to the platform's rules. Use the password manager's supported copy and autofill features and understand its clearing behaviour. Do not assume a web page can erase every system-level copy.
A generated password displayed on screen can also appear in screenshots or screen sharing. Close unnecessary sharing before handling secrets. The tool's exclusion from report exports does not prevent a person from capturing the visible output.
After saving, reset the generator if the secret no longer needs to remain visible. That clears the application's displayed state, but it is not a guarantee of secure erasure from every memory location. The device environment remains part of the security boundary.
Protect the manager and its recovery
A password manager concentrates access to many accounts, so protect it with the provider's recommended authentication and recovery settings. Use a strong master credential where applicable and retain emergency information through a secure process you can actually use.
Test access from a second authorised device or recovery method before losing the first device. Do not store the only manager recovery code solely inside the locked vault it is meant to recover. Keep organisational and personal ownership needs distinct.
For shared business credentials, use the manager's supported sharing and access controls rather than sending plaintext passwords through ordinary chat. Record who owns the account and how access is removed when responsibilities change.
Use breach checks for their specific evidence
The breach checker can identify a password found in its service's corpus. A match is a reason to replace it. No match does not prove strength or uniqueness, so it should not override the generation and storage decisions described here.
A freshly generated password should not be reused merely because it passed a check. The point of a manager is that you do not need to memorise a common secret for every account. Keep the unique-value rule even for low-value services.
For account providers, combine appropriate password handling with rate limits, secure storage and recovery controls. A user-side generator cannot compensate for a service that stores passwords insecurely or authorises account changes incorrectly.
Frequently asked questions
Is a longer password always better?
Length increases the search space when generation is suitably random, but the password must also fit the service and be stored reliably. Avoid unsupported lengths or predictable patterns. A manager-generated unique value within the site's limits is a practical starting point.
Do symbols matter more than length?
Both alphabet size and length affect the theoretical generation space. The formula assumes uniform independent choices. Do not treat one symbol added to a familiar word as equivalent to a randomly generated password of the same length.
Can I reuse a very strong generated password?
Reuse allows one service's compromise to affect other accounts. Generate a different value for each service and save it under the correct entry. The strength of the original generation does not remove credential-stuffing risk after disclosure.
Are generated passwords included in reports?
The included tool separates secret output from its ordinary report exports and print findings. Still review what you copy or capture, and save the secret directly into the intended manager. Screenshots and clipboard history are separate exposure paths.
Should I change every password on a fixed schedule?
Follow current account and organisational guidance, with prompt changes when exposure or compromise is suspected. Arbitrary frequent changes can encourage predictable variations. Unique passwords, secure storage and response to real evidence are more useful than an unexplained calendar rule.
What if I lose the password manager?
Use the recovery process you established and tested in advance. Recovery options vary by product. Keep appropriate emergency information securely outside a circular dependency on the inaccessible vault, and understand the consequences before relying on the manager for every account.
What confirms a password change is complete?
Verify the saved credential logs in, old entries are updated, relevant sessions and recovery settings are reviewed, and the account owner can recover access. Generating a random string is only the beginning of that workflow.