Check password patterns

This checker identifies several especially common shortcuts: walks across neighboring keyboard keys, repeated characters or text blocks, and familiar words disguised with substitutions such as zero for the letter o. It performs a deterministic local pattern analysis and explicitly does not contact a real breach database. The result explains each detected pattern without presenting the check as proof that an undetected password is secure.

Understand what the common-pattern check covers

This checker focuses on three families of choices that people use when they want a password to be memorable but visually busy. A keyboard walk follows consecutive keys, such as a run along the number row or a QWERTY letter row. Repetition includes one character typed at least three times and multi-character blocks copied immediately after themselves. The dictionary check converts familiar substitutions back to letters, removes separators, and looks for a small built-in set of words that attackers commonly prioritize. For example, exchanging an at sign for an a or a zero for an o does not make a familiar word unpredictable. The output names the category and matched fragment so an application can offer specific guidance instead of displaying a vague rejection. Matching one category produces a medium pattern risk; matching two or more produces a high pattern risk. That label describes only these supported patterns, not the password's complete security posture or mathematical strength.

Interpret a clean result with the right caution

A low result means that none of the patterns implemented by this checker appeared. It does not mean the password is strong, unique, private, or absent from historical leaks. The capability deliberately avoids live and downloaded breach databases, so `breach_database_checked` is always false. It also does not estimate entropy, model an attacker's full ruleset, inspect reuse across accounts, or evaluate the system that stores the password. A short name, an uncommon dictionary word, a date, or a personal reference may escape these fixed tests and remain easy to guess. Treat the result as one focused signal in a layered password policy. Favor long, randomly generated credentials or genuinely unrelated passphrases, prevent reuse where possible, add rate limiting and multifactor authentication, and store credentials with a modern password-hashing function. The recommendation returned for a clean result reinforces this boundary instead of awarding a misleading security certificate. This conservative interpretation helps teams use the checker as a precise diagnostic rather than an all-purpose strength meter.

Use the result for clear and privacy-conscious feedback

The response is structured for signup forms, password-change screens, security training, and local policy tooling. `common_pattern_detected` provides a simple branch for user-interface logic, while `patterns` supplies the category, matched fragment, and a short explanation. An interface can therefore say that a keyboard sequence was found or that substitutions still reveal a common word. Avoid logging the input, the match fragments, or the complete response in production analytics because even partial password material is sensitive. Run the free browser version when a user needs immediate local feedback, or call the API for $0.002 per request when integrating the deterministic rule set into an application. An empty password is an input error rather than a low-risk result, which prevents missing form values from being mistaken for safe credentials. Because the algorithm uses fixed tables with no network, randomness, clock, or shared state, identical inputs produce identical outputs. That stability makes policy behavior testable while the explicit breach-check flag keeps product copy honest.