Free · runs in your browser

Keyboard Walk Detector

Keyboard Walk Detector. Drop a password in to instantly spot any keyboard-walk patterns hiding inside it. The free password pattern analyzer gives you a clear, actionable result instantly, with no sign-up required.

Your values

Checked locally in your browser. Runs of 4 or more neighbouring keys on a QWERTY layout are flagged, forward or reverse; Shift and Caps make no difference.

Result

Keyboard walks found
—
Walks detected
—
Pattern map (walks in brackets)
—
Share of password in walks
—
Weak pattern verdict
—
Minimum 8 characters
—
Under 128 characters
—
Not a common password word
—
No keyboard walk
—
No repeated characters
—
Not just l33t-speak substitution
—
No year pattern
—
Contains a digit
—
Contains a special character
—
Mixed case
—
Entropy, every character random
—
Entropy, walks counted as patterns
—
Average crack time, offline fast hash (100 billion guesses/sec)
—
Average crack time, bcrypt cost 12 (10,000 guesses/sec)
—
  • No account, no logging
  • Open formulas explained below
  • Works offline once loaded

Your password can satisfy every complexity rule and still be one of the first strings a cracking tool tries. A keyboard walk detector reads what you typed, maps each character to its key, and flags every stretch where your fingers simply slid across neighbouring keys. You get the exact runs it found, how much of the password they cover, and a realistic estimate of the strength they cost you, so you can fix the weak part instead of guessing which part it is.

How a Keyboard Walk Detector Finds Predictable Password Patterns

A keyboard walk is a run of characters typed on neighbouring keys, the way asdfgh slides along the home row. Because the sequence is quick to type and easy to remember, it feels random to the person who chose it. To a scanner hunting for a predictable password, a single keyboard walk pattern is a short, well-known path. Need to calculate a password expiry date? There is a free, no-sign-up tool for exactly that.

Detection starts with the keyboard layout. Every key gets an x and y coordinate, with each row shifted to the right of the one above it, just as the physical keys are staggered. Two keys count as neighbours when the distance between them is about one key width. Shifted symbols fold back onto their base key, so !QAZ and 1qaz trace the same path, and capital letters make no difference.

Sequential Keys: Row, Column and Diagonal Walks

A row walk follows one line of keys, as in poiuyt. A column walk steps down through the stacked rows, as in 5tgb or 6yhn, and because the rows are staggered the path drifts sideways as it falls, which is why people also call it a diagonal walk. Walks can be chained, too: 3edc4rfv is two short column walks joined at the top. Every one of these is a sequential run in physical space even though the letters look unrelated on screen.

A detector only flags a run once it reaches a minimum number of keys. Four is a sensible floor, because two or three neighbouring keys turn up by chance in ordinary words, while four or more almost never do.

Forward and Reverse Walks on the Qwerty Layout

Typing direction does not hide anything. The detector checks forward and reverse runs on the same path, so mnbvc reading right to left along the bottom row is just as visible as cvbnm reading left to right. The qwerty layout is where most walks are studied, but the same coordinate approach works for AZERTY, QWERTZ and Dvorak once you swap in that layout's key map.

The same key map that powers a detector also powers a keyboard walk generator, which steps across the keys to produce candidate strings. Whatever a generator can produce in seconds, the detector flags just as quickly, which is why it checks both directions.

Why Keyboard Walk Patterns Show Up in Compromised Passwords

Every time a data breach leaks a database, the passwords inside join the lists that cracking tools try first. Walks are fast to type and easy to remember, so they appear again and again in those leaks. Attackers load them into a wordlist next to the usual leet substitutions and year endings, and you pay the price whenever one of your own passwords follows the same path. The password similarity comparator runs entirely in your browser — nothing you enter is ever sent to a server.

Common Password Lists and Breach Data

A common password list is just leaked passwords sorted by how often they occur. Walk fragments sit near the top because thousands of people choose them independently. If a fragment is in the list, a high-probability guess lands within the first few thousand tries, long before anyone attempts a full search.

Leaks also fuel credential stuffing, where an exposed pair of email and password is replayed against other sites. This is where password reuse hurts most: a walk that felt harmless on a forum becomes the key to your bank when the same string is used there, and a detector catches that string before you reuse it. Sites that store only a salted hash make the offline work slower, and strong encryption of the database adds another layer, but neither can stop a guess that is already in the list, so the weak string itself has to go.

Password Spraying and Active Directory

In a password spraying attack, someone tries a single likely password, often a walk, against every account in an Active Directory domain, then waits before trying the next one so the lockout threshold is never reached. One weak account is enough. Logs from an exposed SSH honeypot show the same habit, with simple walks among the guesses, and the detector flags the exact walk a sprayer would try first.

Where Brute Force Fits In

Raw brute force comes last. Cracking software works through leaked lists, then rule-based mutations, then patterns such as walks, and only then tries every combination. A walk lets someone skip that last, expensive stage entirely, which is why the detector reports it on its own rather than folding it into a general strength score. The first time you see your own password cracked in an audit, it is almost always by one of the earlier, cheaper stages.

Worked Example: Spotting the Password Walk in Bluefin#mnbvc9876

Take the 17-character password Bluefin#mnbvc9876. It mixes upper and lower case, a symbol and a digit run, so a rule-based checker would wave it through. The detector maps every character to its key and finds two runs of four or more neighbouring keys. Bluefin# contains none.

Worked Example: Spotting the Password Walk in Bluefin#mnbvc9876
Part of the passwordCharactersKeys walkedDirection
Bluefin#8No run of four or moreNone
mnbvc5Bottom letter rowRight to left
98764Number rowRight to left

The two walks cover 9 of the 17 characters, so more than half the password follows the keys rather than your own choice:

$$\text{coverage} = \frac{\text{walk characters}}{\text{password length}} = \frac{5 + 4}{17} \approx 52.9\%$$
QWERTY keyboard map highlighting the reverse bottom-row walk mnbvc and the reverse number-row walk 9876 that cover 9 of 17 characters in one password
Where the detector finds the two walks in Bluefin#mnbvc9876: 9 of 17 characters, or 52.9%, follow neighbouring keys.

Estimating Entropy and Crack Time

Standard entropy treats every character as a random pick from the character set. With the 95 printable ASCII characters, each one is worth about 6.57 bits, so the whole password looks like this:

$$H = L \times \log_{2}(N) = 17 \times \log_{2}(95) \approx 111.7 \text{ bits}$$

A walk is not 5 or 4 independent picks. To reproduce one, an attacker only has to choose a start key (about 40 options) and a direction (about 8), which is roughly log2(40 × 8), or 8.3 bits per walk, whatever its length. Replacing each walk with one such token gives the pattern-aware estimate:

$$H_{\text{walk}} = (17 - 9) \times 6.57 + 2 \times 8.32 \approx 69.2 \text{ bits}$$
Estimating Entropy and Crack Time
ComponentCharactersNaive bitsPattern-aware bits
Bluefin#852.652.6
mnbvc532.88.3
9876426.38.3
Total17111.769.2

The two walks remove 42.5 bits, about 38% of the apparent strength. Treat the result as a ceiling, not a verdict: it still assumes Bluefin# is random, and a real wordlist would reach a dictionary word far faster. Any crack time figure built on it is generous, which is why the list of flagged walks matters more than the final number.

Waterfall chart showing a password's entropy falling from 111.7 bits to 69.2 bits after removing the mnbvc and 9876 keyboard walks
Counting each walk as one token removes 42.5 bits from the random-looking 111.7-bit estimate.

Replacing the Walks

Swap the walks for characters from a password generator and the detector reports zero runs. In the example, the last 9 characters become something like kT4vq2Rj9: same length, no neighbouring keys, and the full 111.7-bit estimate holds under the same assumption. Keep the length, drop the path.

Catching a Password Walk in a New Router Admin Login

Dana is setting the admin login for a dental office's Wi-Fi router, and the draft is Quill7!lkjhg2Linen: a word, a digit and a symbol, then lkjhg, then another digit and a second word. At 18 characters it clears the 15-character minimum that NIST SP 800-63B (revision 4) sets for a password used as the only login factor, so Dana expects a clean result.

Dana pastes it into the keyboard walk detector. The report comes back at once with one walk, lkjhg, characters 8 to 12, five keys running right to left along the home row. Coverage is 5 of 18 characters, or 27.8%. The all-characters estimate is 118.3 bits; with the walk counted as a single 8.3-bit token, the pattern-aware estimate is 93.7 bits.

Both figures look comfortable, which is exactly why Dana reads the walk rather than the bits. Those five letters came from thinking "just slide left", and that is the path a leaked list reaches without testing a full combination. The 93.7 bits also treats Quill and Linen as random characters, so the real margin is thinner.

Catching a Password Walk in a New Router Admin Login
DraftWalks foundCoveragePattern-aware estimate
Quill7!lkjhg2Linen1 (lkjhg)27.8%93.7 bits
Quill7!kRw9d2LinenNone0%118.3 bits

The fix is a single swap. Dana replaces lkjhg with kRw9d, five characters with no neighbouring keys, and reruns the check: 0 walks, 0% coverage, and the estimate returns to the full 118.3 bits. The new password goes into the office's shared vault, and Dana adds one line to the setup sheet: no run of four or more neighbouring keys, in either direction.

Blocking Keyboard Walks with a Password Policy

Telling people to add numbers and symbols does little against walks, because mnbvc9876 already contains both. NIST SP 800-63B moved away from composition rules for this reason and instead asks services to reject choices that appear in leaked lists, dictionaries and repetitive or ordered strings. A good password policy therefore pairs a minimum length with a check for walks and a block on leaked passwords.

Where the directory software allows it, a custom dictionary of common walks does the job at password change time, so the user sees the rejection straight away instead of learning about it in an audit. Rejecting at the keyboard also keeps weak strings out of every future leak.

  • Set a length floor. Long strings give a walk less room to dominate the result.
  • Reject runs of four or more neighbouring keys in either direction.
  • Screen against known leaks as well, because a walk-free password can still be reused.
  • Explain the rejection so people learn what to avoid.

Limits of a Browser-Based Keyboard-Walk Check

A detector like this runs in your browser, so nothing is sent to a server and your password never leaves the page. That privacy has a cost: it cannot look your password up in a leak database. A string with no walks can still sit in a leak, so a clean result is one signal of password hygiene, not a full security audit of your accounts, and the risk of reuse remains.

It also cannot see words. Names, dates and pet names are the most common vulnerabilities after walks, and a pattern check does not catch them. Combine it with a length check, a leak lookup and, where you can, a manager that creates the password for you.

When a Password Manager or Passphrase Is Better

The most reliable fix for any pattern is to stop choosing the password yourself. A password manager creates and stores a different long string for every site, which also ends reuse. When you must memorise one, a passphrase of unrelated words is easier to recall than symbols and holds up far better than a walk dressed with numbers and symbols.

For cybersecurity teams the practical goal is simple: a walk the detector flags is one that hackers could generate in a minute, so it should never protect an account.

Frequently Asked Questions

What counts as a "keyboard walk"?
A sequence of characters that are physically adjacent to each other on a standard QWERTY keyboard -- like "qwerty", "asdfgh", "1qaz", or "zxcvbn" -- typed in order along a row, or in reverse. These feel random to type quickly but follow a completely predictable physical pattern rather than being genuinely random.
Why are keyboard walks considered weak?
Password-cracking wordlists and tools check for keyboard walks specifically, right alongside dictionary words and common passwords -- because they're an extremely common shortcut people take when asked to create a password quickly. A pattern that's easy for a human to type from muscle memory is just as easy for an attacker's tool to guess.
Does this only check horizontal rows?
Yes -- this tool checks the four standard QWERTY rows (number row, top letter row, home row, bottom row) in both forward and reverse order. It doesn't currently check diagonal or vertical adjacency (like "1qaz2wsx"), which is a narrower and less commonly exploited pattern.
I found a keyboard walk in my password -- what should I do?
Replace that segment with something unrelated to key position -- ideally switch to a passphrase built from random unrelated words (see this site's Passphrase Generator), or a fully random password from the Password Generator, rather than trying to patch just the flagged section.
Is my password sent anywhere?
No. The entire check runs locally in your browser using this site's own pattern data -- nothing is transmitted to a server or stored.

About the author

Vinitha Pu

Founder and designer

Vinitha Pu is a graphic designer based in Palakkad, Kerala, who builds free, privacy-friendly browser tools. She studied Textile and Apparel Design at Avinashilingam University and completed a C-Tech in Graphic Design at Image Creative Education in 2025. She designs, builds and maintains the password generators, strength checkers, hash tools and security calculators on PasswordHive.

  • Content author: Vinitha Pu
  • Fact checked by: Vinitha Pu. Each tool's output is checked against official test vectors or a reference implementation, and every strength and crack-time figure against the formula it uses, before it goes live.
  • Published Updated