Calculation notebook · use case

Choose a Random Password Length and Character Set

A password generator should produce unpredictable values locally, not advertise a fixed “strong” example for everyone to copy. Length, permitted characters, storage and reuse all matter. A larger theoretical search space does not guarantee safety after phishing or a credential leak.

Start with the service’s acceptance rules

Check its maximum length and supported symbols. Select enough character categories to satisfy the policy, but avoid a character set that the service rejects. An ambiguous-character option can remove visually similar symbols for manual transcription; it reduces alphabet size and is a convenience trade-off, not additional entropy.

Separate alphabet size from password length

For independent uniform choices from an alphabet of A characters, the unconstrained space is A^L for length L. With 26 letters and length 12, there are 26^12 possibilities. Adding one character multiplies that space by 26. Requiring every selected category to appear changes the count, so L log₂ A is a simple upper-model estimate rather than an exact guarantee for the constrained generator.

Use the right random source

Cryptographic generation uses the platform’s secure random source. A predictable sequence designed for simulations is inappropriate. Selecting a random byte and taking a remainder can create modulo bias unless the selection method accounts for it; the generator should preserve uniform selection rather than merely displaying random-looking text.

Treat the output as a secret

Use a password manager when possible, generate a different value for every service and avoid pasting passwords into support tickets or screenshots. The worked example should check length and selected character categories without recording a reusable sample secret. Clipboard contents may be visible to other software and should be handled accordingly.

Verify structure, not a marketing strength label

Confirm the chosen length and that required selected categories occur. When all categories are required, the length must provide at least one position for each. A mathematical count cannot predict compromise time without a threat model, hashing setup and attack conditions; avoid presenting a precise crack-time promise.

Count the available characters without claiming exact entropy

The default pools contain twenty-six uppercase letters, twenty-six lowercase letters, ten digits and thirteen listed symbols, for seventy-five available characters. Excluding I and O, l and o, and 1 and 0 removes six, leaving sixty-nine. The option improves transcription consistency while making the alphabet smaller. Its benefit should be described as readability, not as a larger guessing space or a guaranteed security improvement.

For a deliberately unconstrained independent-uniform model, increasing a twenty-six-letter password from twelve to fourteen positions multiplies its space by 26² = 676. Increasing a thirty-two-character model from twelve to sixteen positions multiplies its space by 32⁴ = 1,048,576. These ratios illustrate the role of length without publishing a sample credential. The implemented generator also requires every selected category, so these unrestricted models are not an exact entropy audit of its final distribution.

Independent uniform unconstrained model, without category requirements; not the implemented generator’s exact entropy
Alphabet sizeLengthUnconstrained stringsTheoretical model bits: L log₂ A
261226^1256.4
261426^1465.8
321232^1260
321632^1680

Explain why the random-source mapping is part of the method

A 32-bit random integer has 4,294,967,296 possible values. With a seventy-five-character pool, that total is not divisible by seventy-five: the remainder is forty-six. Taking every value modulo seventy-five would give some characters one extra preimage. Rejection sampling instead accepts values below 4,294,967,250, a multiple of seventy-five, and draws again for the forty-six values outside that range.

This mapping preserves uniform selection for each individual draw when the platform source supplies uniform random integers. It is separate from the selected-category rule and the final shuffle. The generator deliberately inserts at least one character from each chosen pool before filling and shuffling; it should not claim uniformity across all category-constrained strings merely because each individual random index avoids modulo bias.

Validate service constraints before generating a secret

With all four categories selected, the minimum length that can include one of each is four. A length of three is therefore rejected, rather than silently dropping a category. The maximum supported length is 128. A service may impose its own lower maximum, restrict symbols or reject some Unicode input; the tool generates from its explicit ASCII pools and does not know the destination service’s policy.

If the service requires only letters and digits, disable the symbol pool before generation instead of deleting symbols afterward. Editing a generated result can reduce its length, remove the only representative of a required category or introduce a predictable human pattern. If a result is rejected by the service, revise the allowed pools and regenerate a new value rather than repeatedly modifying a rejected secret into a familiar shape.

Verify structure without logging reusable credentials

A verification record can state the requested length, enabled category names, ambiguity option and whether the output satisfies those constraints. It does not need the generated characters. Automated tests should likewise inspect the length and class presence without printing a password as a fixed success example. Neither the input secret nor generated output belongs in page analytics, screenshots attached to public issues or tutorial tables.

Use the platform’s cryptographic source over HTTPS or localhost, and treat a missing source as an error rather than falling back to a simulation generator. Store independent credentials in an appropriate password manager and consider separate authentication protections. Clipboard contents and the surrounding device remain security considerations even when generation is local. This tool does not detect compromise, assess a password against a breach corpus, promise an attack duration or eliminate phishing and reuse risks.

Questions and checks

Is one longer password always safer than a short mixed one?

Length increases the theoretical space, but comparisons also need the alphabet, selection method and service rules. Reuse and phishing remain separate risks.

Does removing ambiguous characters improve security?

It improves readability while reducing the alphabet. Compensating with more length can increase the search space.

Should I save a generated example in analytics?

No. Analytics should record event type, not the secret or entered values.

Sources and scope

The examples are illustrative calculations, not records of individual users. Check the policy or measurements that apply to your situation.

Try the calculations