Secure Password Generator

Generated Password

1 password ready Length {{ normalizedLength }} {{ poolSize }} chars in pool {{ entropyBits.toFixed(1) }} bits entropy {{ crackTimeSummary }} {{ strengthLabel }} strength History {{ history.length }}

Preset:

Length:

chars:

Uppercase:

A–Z

Lowercase:

a–z

Numbers:

0–9

Symbols:

!@#$…

Exclude ambiguous:

Remove 0 o O 1 l I

Require each type:

Ensure coverage

Unique characters:

No repeats

Extra characters:

Characters to avoid:

No data yet. Generate a password to review metrics.

Metric	Value	Copy
{{ row.label }}	{{ row.value }}

History is empty. Generate passwords to build a list.

Password	Entropy (bits)	Strength	Copy
{{ row.password }}	{{ row.entropy.toFixed(1) }}	{{ row.strength }}

Charts appear once at least one character set is active.

JSON view becomes available after generating a password.

Tags: Cryptography , Randomness , Security

Export to PDF Fullscreen

Include query parameters

Embed:

Customize embed code

Include query parameters

Wrap embed in collapsible toggle

Collapse panel by default

Hide card frame (bare iframe)

Loading behavior

Width

Height

Aspect ratio (width : height)

Max height (optional)

Collapsible heading

Collapsible description (optional)

Allow fullscreen

Referrer policy

Sandbox tokens

Random passwords work best when each character is hard to predict and the total search space grows faster than an attacker can test guesses. The two biggest levers are length and the number of allowed characters at each position. That is why a longer random string usually buys more real protection than a short password that only adds a predictable digit or symbol at the end.

Current password guidance has moved away from treating uppercase letters, numbers, and symbols as a magic recipe. Length, uniqueness, and resistance to common patterns matter more in practice than satisfying a ceremonial character-mix rule. For many accounts, the strongest habit is to let a generator create a fresh secret and store it in a password manager instead of trying to invent memorable variations by hand.

Diagram showing character pool, length, and pattern checks feeding practical password strength.

Usability still matters. Some systems reject symbols, some people need to transcribe a credential from paper, and some workflows still ask for a short numeric PIN. Those constraints are real, but every restriction changes the pool size or the allowed structure. A good generator makes those tradeoffs visible instead of hiding them behind a single color bar.

No strength estimate is a blanket guarantee. Phishing, malware, password reuse, and weak storage on the service side can undo a mathematically strong secret. The safest reading is comparative: use the search-space math to understand what the settings buy you, then use the pattern-aware feedback and the account context to decide whether the result is truly good enough.

Technical Details:

Entropy in this context is a shorthand for how many equally likely choices remain once the active character pool and the requested length are set. If the pool has N characters and the password has L positions, the displayed search space is N^L and the displayed entropy is L × log2(N). The crack-time estimate then divides that space by a fixed benchmark of 10^10 guesses per second, which is intentionally harsh and best read as an offline fast-hash comparison point rather than a promise about a live sign-in form.

That mathematical view is only part of the picture. Recognizable structure still matters, which is why the result area also shows a zxcvbn score from 0 to 4, labeled Very Weak, Weak, Fair, Good, and Strong. When the formula and the heuristic disagree, the safer interpretation is to trust the harsher warning rather than the larger number.

\begin{array}{lll} H & = & L {log}_{2} (N) \\ C & = & N^{L} \\ t_{sec} & = & \frac{C}{10 \times 10^{9}} \end{array}

The formulas above describe the displayed upper bound. They do not model rate limits, breached-password blocklists, phishing, or account takeover paths that bypass guessing entirely. They are still useful because they make the impact of length, exclusions, and character-pool changes easy to compare.

Character Pool Rules:

Character pool contributions in the secure password generator
Source	Available before lookalike filter	Available after lookalike filter	Notes
Uppercase letters	26	24	`O` and `I` are removed when lookalikes are excluded.
Lowercase letters	26	24	`o` and `l` are removed when lookalikes are excluded.
Digits	10	8	`0` and `1` are removed when lookalikes are excluded.
Symbols	32	32	Punctuation is unaffected by the built-in lookalike filter.
Extra characters	Variable	Variable	Duplicates collapse to one entry, and overlaps or exclusions do not add new pool size.

Require each type and No repeats change how the password is assembled, but the displayed entropy and crack-time math still use the simpler pool-size model. That keeps the metrics easy to compare across presets and lengths, yet it also means the numbers are best treated as high-level guidance when extra constraints narrow the valid output set.

Generation Bounds and Failure Conditions:

Validation rules in the secure password generator
Condition	Rule	Practical effect
Length	Rounded and clamped to `4` through `128`.	Very short and excessively long requests are normalized before generation.
Active pool	At least one enabled set or extra character must remain after exclusions.	If nothing remains, generation stops with an error instead of returning an empty or misleading result.
Require each type	`Length ≥ number of active sets`.	A four-type setup cannot fit into three characters and is rejected immediately.
No repeats	`Length ≤ active pool size`.	A digits-only pool cannot produce a 12-character unique password because only 10 digits exist.
Extra and excluded character fields	Each accepts up to `128` typed characters.	They are best used for site-specific compatibility, not as a substitute for adding more length.

Everyday Use & Decision Guide:

Strong is the sensible default for most account passwords: 16 characters with uppercase, lowercase, digits, symbols, lookalikes removed, and every enabled type represented. If a site refuses symbols, Long is usually the better fallback because it stretches the password to 24 characters instead of shrinking it into a short compromise.

PIN is different. It exists for devices or workflows that truly require digits only, not as a general substitute for an account password. A six-digit PIN still has only 10^6 possible combinations, so it should stay scoped to the specific place that asked for a PIN.

Leave Exclude ambiguous on when you may need to read or type the password manually. It slightly shrinks the pool, but it can prevent avoidable copy errors.
Use Require each type when a site policy still insists on mixed categories. It helps policy fit, but length still matters more than decorative category coverage.
Use Extra characters and Characters to avoid for real site-specific rules. Adding a character that is already present in another set does not enlarge the pool.
Open Details first. The fastest trust check is the combination of Length, Active pool size, Entropy, Crack time @10B/s, and Strength.
Use History when you want to compare recent generations and Entropy Trends when you want to see what a few more characters would do with the current pool.

Changing a preset or option immediately produces a fresh password. That makes experimentation quick, but it also means the current candidate can disappear from the main result as soon as you tweak a setting. If you are comparing candidates, glance at History before you move on.

Generation, scoring, charting, and exports all happen in the browser. The option set can be mirrored into the page URL for sharing, but the generated password, history list, and exported summaries are not written into the query string. Even so, copied text, downloaded files, and open tabs still deserve the same care as any live credential.

Step-by-Step Guide:

Choose Strong, Long, PIN, or stay on Custom if you already know the target system's rules.
Set the length and the core character types first. That decides most of the search space before any fine-tuning begins.
Open Advanced only if you need compatibility controls such as lookalike removal, required type coverage, no repeats, extra allowed characters, or explicit exclusions.
Use Regenerate until the candidate fits the target system. Changing options also creates a new password automatically, so the button is mainly for another draw with the same rules.
Check Details for the pool size, entropy, crack-time benchmark, zxcvbn label, and option summary before you trust the result.
If you are deciding between candidates, use History for side-by-side comparison and Entropy Trends to see how the current pool behaves across nearby lengths.
Copy or download the final password, then store it in a password manager instead of keeping it in notes, screenshots, or repeated browser tabs.

Interpreting Results:

The result strip answers three different questions. Length and Active pool size show the raw search space you are working with. Entropy and Crack time @10B/s turn that into a rough offline benchmark. Strength is the pattern-aware warning light. Good decisions come from reading all three together, not from chasing only the largest number.

How to read the secure password generator outputs
Result cue	What it usually means
`Strength = Very Weak` or `Weak`	Reject the candidate. The string still looks cheap to guess, even if it contains mixed character types.
`Entropy` rises but `Strength` stays modest	The formula sees a larger pool or longer length, but the finished string may still resemble a known pattern. Trust the harsher signal.
`Crack time @10B/s` stays in seconds, minutes, or hours	The password is still too small for a high-value account under a harsh offline benchmark. Add length or widen the pool.
`Active pool size` drops after exclusions	That is expected when lookalikes or forbidden characters are removed. Compensate with more length if the site allows it.
Generation error appears	The settings are impossible, not unlucky. Shorten the length, relax the constraints, or restore more characters to the pool.

A huge crack-time estimate does not protect against password reuse, phishing, or a compromised device. Before you trust a candidate, make sure it is unique to the account and that you did not simplify it manually while typing or copying it into the destination system.

Worked Examples:

Strong preset for a password-manager entry

Strong combines uppercase letters, lowercase letters, digits, and symbols at a length of 16, while removing the built-in lookalikes. That leaves an 88-character pool: 24 uppercase letters, 24 lowercase letters, 8 digits, and 32 symbols. The displayed entropy is about 103.4 bits, and the crack-time benchmark lands around 10^13.6 years. The exact zxcvbn label still depends on the finished string, but this is a strong starting point for a stored account password.

Long preset when symbols are not allowed

Long removes symbols but stretches the length to 24. With lookalikes still excluded, the pool becomes 56 characters and the displayed entropy rises to about 139.4 bits. That is a much better compromise than shrinking to a short alphanumeric password just because the site refuses punctuation.

Digits only with no repeats

Turn on digits only, enable No repeats, and ask for a length of 12. Generation fails because the pool has only 10 unique digits. The fix is not to keep regenerating. Shorten the request to 10 or less, or allow repeats again. If the target system really only needs a short PIN, keep that PIN confined to the device or workflow that asked for it.

FAQ:

Does the password leave the browser?

Generation, scoring, history, charting, and exports are built in the browser, and the generated password itself is not written into the page URL. Only the option set can be mirrored into query parameters for sharing.

Does it use cryptographically strong randomness?

Yes when the browser exposes crypto.getRandomValues. If that API is missing, generation falls back to ordinary pseudo-random selection, which is a weaker safety net for old or limited environments.

Why can higher entropy still show only Fair or Good strength?

Because the entropy formula assumes independent random draws from the active pool, while zxcvbn penalizes recognizable patterns. The math may improve when the pool grows, yet the heuristic can still hold back the verdict if the finished string looks too guessable.

What does No repeats really change?

It prevents a character from being reused until the active pool is exhausted. That can be useful for a specific policy or preference, but it does not automatically beat simply adding more length, and the displayed entropy math does not switch to a no-repeat permutation formula.

Why did generation fail?

The usual causes are an empty pool after exclusions, too many required character types for the requested length, or a no-repeat request that needs more unique characters than the pool can supply. The fix is to adjust the constraints, not to keep clicking regenerate.

How long does History last?

The page keeps up to 20 recent passwords in memory for the current session. Reloading or closing the page drops that list.

Glossary:

Active pool size: The number of distinct characters currently available after all enabled sets, extra characters, and exclusions are combined.
Entropy: The displayed bit estimate derived from length and active pool size under an independent-draw model.
Lookalikes: The built-in ambiguous characters 0, o, O, 1, l, and I that can be removed to reduce transcription errors.
zxcvbn score: The 0 to 4 heuristic score that labels the password from Very Weak through Strong.
Crack-time benchmark: The displayed estimate produced by dividing the formula-based search space by 10^10 guesses per second.