Password handling

Generate passwords locally, then protect them properly

A password generator solves one narrow problem: creating an unpredictable secret. It does not store the secret, recover an account, or secure a login system by itself.

Content updated: · Maintainer and corrections

Test the password field without reusing a secret

Choose a length and character groups accepted by the test service, generate a fresh value, and paste it into that service once. Check whether the field truncates input, changes whitespace, or blocks paste. A registration success message is not sufficient: sign out and verify that the same test value works on sign-in.

If the service rejects a value, inspect its documented limit before reducing length or removing character groups. Do not repeatedly modify a real password until it passes. Keep a separate disposable account for this test and remove copied test secrets from shared documents and screenshots.

For a real account, save the unique generated value in your password manager before leaving the page. Reloading or regenerating can replace the displayed result. Follow the service’s recovery setup separately; this generator has no account recovery function.

Generate once per account

Create a distinct random password for every service and put it directly into a trusted password manager. Reusing a memorable variation turns one breached site into a risk for every account.

Keep secrets out of examples

Use a throwaway value when testing forms, screenshots, or documentation. Do not paste a production password into a browser tool, ticket, chat, commit, or client-side log.

Generation is not password storage

A service that accepts passwords needs a dedicated server-side password hashing design, rate limiting, recovery controls, and transport security. Never substitute a general checksum for password hashing.

Use a unique generated test password; never reuse it for a real account.

Data provenance

Sources