How to password entropy and crack-time auditor
- Step 1Open the auditor and confirm it is offline — Load the page, open DevTools → Network, and start typing. You will see no outbound request carrying your password — the
passwordfield issecretand analysis runs in-page. This is the one safe way to test a password you actually use. - Step 2Type or paste the password into the single input — There is exactly one control: a
passwordtext field. No options, no presets, no character-class checkboxes. Paste a candidate from your manager or type a passphrase you are considering. It stays in browser memory only. - Step 3Read the 0–4 score first — Score 4 = the strongest band (
guesses_log10≳ 10 for offline-fast resilience); 3 = safe against throttled online attack but crackable offline if the hash leaks; 2 and below = strengthen it. The score is zxcvbn's coarse bucket — the crack-time rows below it are the real detail. - Step 4Compare the four crack-time figures to your threat model — If you only care about someone guessing at a login form, read
online_throttling_100_per_hour. If you care about a breached password database, readoffline_fast_hashing_1e10_per_second— that row exposes passwords that look fine online but fall inless than a secondto a GPU. - Step 5Act on the matched patterns and suggestions — The
sequencearray tells you *why* it is weak (dictionary:passwords,repeat,date,spatial). Thefeedback.suggestionsgive the fix — usually 'Add another word or two' rather than 'add a symbol'. Capitalisation and@-for-asubstitutions are explicitly called out as nearly worthless. - Step 6Iterate, then store the winner — never leave it in the box — Adjust the passphrase, re-audit, and watch
guesses_log10climb. Once you reach score 4, generate the real secret in a password manager and clear the field. For anything you will reuse, follow up with aes-256-encryptor for files or pgp-message-signer for messages.
What the auditor reports (zxcvbn 4.4.2 output fields)
Every field returned for a single password. The browser tool exposes the full JSON plus a findings summary (score, crackTime, feedback); the API path returns score, crackTime, feedback, and guesses.
| Field | What it means | Example value |
|---|---|---|
score | Coarse 0–4 strength bucket derived from the guess estimate | 0 (too guessable) … 4 (strong) |
guesses | Estimated number of guesses an attacker needs — the core metric everything else derives from | 19058000 for Tr0ub4dour&3 |
guesses_log10 | Base-10 log of guesses; the cleanest way to compare two candidates numerically | 7.28 (≈10 million guesses) |
crack_times_display | Human-readable crack time under four attacker speeds | { offline_fast_hashing_1e10_per_second: "less than a second", … } |
sequence | Array of matched chunks, each with a pattern (and dictionary_name for dictionary hits) | [ "dictionary:passwords", "bruteforce" ] |
feedback.warning | One short headline problem, or empty string if none | "This is a top-10 common password" |
feedback.suggestions | Concrete fixes, guessability-first not complexity-first | ["Add another word or two. Uncommon words are better."] |
calc_time | Milliseconds zxcvbn spent scoring (it is fast — single-digit ms) | 3 |
The four crack-time scenarios explained
zxcvbn reports the same password against four attacker assumptions. Match the row to YOUR threat model — a password can be 'centuries' online and 'less than a second' offline.
| Scenario field | Attacker speed | Real-world situation it models | Read this row when… |
|---|---|---|---|
online_throttling_100_per_hour | 100 guesses/hour | A login form with rate limiting / lockout after failed attempts | You only fear someone guessing at the live login page |
online_no_throttling_10_per_second | 10 guesses/second | A login endpoint with no rate limit, or credential stuffing | The service has weak or no brute-force protection |
offline_slow_hashing_1e4_per_second | 10,000 guesses/second | A leaked database hashed with a slow KDF (bcrypt / scrypt / Argon2) | The site's hashes leaked but they used a proper KDF |
offline_fast_hashing_1e10_per_second | 10 billion guesses/second | A leaked dump hashed fast/unsalted (MD5/SHA-1), cracked on a GPU rig | Worst case — this is the row that exposes deceptively-weak passwords |
Score bands and what the patterns mean
zxcvbn's 0–4 score maps to a rough guesses_log10 band. The sequence patterns name the structural weakness it detected.
| Pattern in `sequence` | What zxcvbn matched | Typical effect on score |
|---|---|---|
dictionary:passwords | Your input is in the common-password list (top-10k from breaches) | Crushes the score to 0–1 (e.g. password, qwerty12345) |
dictionary:english_wikipedia / surnames / us_tv_and_film | A recognised English word, name, or pop-culture term | Cheap individually; safe only when you chain several uncommon ones |
repeat | Repeated characters or words (aaaaaaaa, abcabcabc) | Score 0 — aaaaaaaa cracks in less than a second offline |
spatial | Keyboard walk (qwerty, asdfgh, 1qaz2wsx) | Treated as a single cheap token, not random characters |
sequence | Run of consecutive characters (abcdef, 123456) | Adds almost no guesses |
date | A recognisable date (1990, 01/01/2020, 2024) | Years are very cheap; Summer2024! lands at score 2 |
bruteforce | The leftover characters zxcvbn could not match to any pattern | The only chunk that genuinely adds entropy — maximise this |
Cookbook
Real zxcvbn 4.4.2 outputs for passwords people actually pick. guesses_log10 is rounded; crack times are the verbatim crack_times_display strings. Notice how character-class 'strength' and real guessability diverge.
The classic that fools complexity meters: P@ssw0rd
It has upper, lower, digit, and symbol — a perfect score on most checklist widgets. zxcvbn scores it 0: it is a single common password with predictable leet substitutions, which it explicitly says don't help.
Input: P@ssw0rd zxcvbn report (abridged): score: 0 guesses_log10: 1.23 (≈ 17 guesses) sequence: [ "dictionary:passwords" ] crack_times_display: online_throttling_100_per_hour: 10 minutes offline_fast_hashing_1e10_per_second: less than a second feedback.warning: "This is similar to a commonly used password" feedback.suggestions: - Predictable substitutions like '@' instead of 'a' don't help very much - Capitalization doesn't help very much
The passphrase that wins: correct horse battery staple
No uppercase, no digits, no symbols — it would FAIL a complexity rule. zxcvbn scores it the maximum 4 because four uncommon words chained together push the guess count past 10^20.
Input: correct horse battery staple zxcvbn report (abridged): score: 4 guesses_log10: 20.33 (≈ 2 x 10^20 guesses) sequence: [ dictionary, bruteforce, dictionary, ... ] crack_times_display: online_throttling_100_per_hour: centuries offline_fast_hashing_1e10_per_second: centuries feedback.warning: "" (none) feedback.suggestions: [] (nothing to fix)
Looks safe online, dies offline: Summer2024!
A seasonal password with a year and a bang. Throttled, it survives 31 years. But it is a common-password root plus a cheap date, so against a GPU dump it falls instantly — read the offline row, not the online one.
Input: Summer2024! zxcvbn report (abridged): score: 2 guesses_log10: 7.44 sequence: [ "dictionary:passwords", "bruteforce" ] (2024 = cheap date/year) crack_times_display: online_throttling_100_per_hour: 31 years offline_fast_hashing_1e10_per_second: less than a second feedback.warning: "This is similar to a commonly used password" feedback.suggestions: - Add another word or two. Uncommon words are better. - Capitalization doesn't help very much
Pure repetition collapses: aaaaaaaa
Eight characters, but all the same. zxcvbn matches a single repeat token, so the guess count is tiny regardless of length. A 40-character aaaa... would score no better.
Input: aaaaaaaa zxcvbn report (abridged): score: 0 guesses_log10: 1.99 sequence: [ "repeat" ] crack_times_display: online_throttling_100_per_hour: 58 minutes offline_fast_hashing_1e10_per_second: less than a second feedback.warning: 'Repeats like "aaa" are easy to guess' feedback.suggestions: - Avoid repeated words and characters - Add another word or two. Uncommon words are better.
Short random vs. memorable: 4f9a2c8e1b
A 10-char hex string from a generator. zxcvbn can't match it to any dictionary, so the whole thing is bruteforce — score 3, centuries online but only ~1 second offline because it is short. Length still matters even for random secrets.
Input: 4f9a2c8e1b zxcvbn report (abridged): score: 3 guesses_log10: 10.0 sequence: [ "bruteforce" ] crack_times_display: online_throttling_100_per_hour: centuries offline_fast_hashing_1e10_per_second: 1 second feedback.warning: "" Takeaway: 16+ random chars (or use the passphrase route) for offline-safe.
Edge cases and what actually happens
Empty input — nothing typed
RejectedIf the password field is empty the tool throws Enter a password to audit. and produces no report. There is no default and no placeholder password — you must supply a string.
Password contains your own name or email
Not detected herezxcvbn supports a user_inputs dictionary (name, email, username) so it can penalise passwords built from your identity — but this tool calls zxcvbn with the password only and passes no user-context list. So john1990 is scored against the generic dictionaries, not flagged as 'contains your name'. Treat any personal-data password as weaker than the score implies.
Very long passphrase (50+ characters)
SupportedLength is handled fine; zxcvbn parses the whole string and calc_time stays in single-digit milliseconds. The score is capped at 4, so a strong 30-char passphrase and a strong 80-char one both show score 4 — compare guesses_log10 if you want to see the (large) difference between them.
Emoji, accents, or non-ASCII characters
Supportedzxcvbn operates on the JavaScript string, so emoji and accented letters are accepted and counted as characters it can't dictionary-match (they fall into bruteforce). They don't trigger errors. Just remember some login systems mangle or reject non-ASCII on entry, independent of how strong zxcvbn rates it.
Leetspeak substitutions (P@ssw0rd, l33t)
By designzxcvbn reverses common substitutions (@→a, 0→o, 3→e, 1→i) before dictionary matching, then adds only a small bonus for the substitution. This is why P@ssw0rd scores 0 and the feedback says substitutions 'don't help very much'. Not a bug — it mirrors how real cracking rulesets work.
Keyboard walk such as 1qaz2wsx or qwerty
By designThese match the spatial pattern and are scored as one cheap token, not as random characters. qwerty12345 lands at score 1 (13 hours throttled, less than a second offline) despite mixing letters and digits.
Score 4 but a fast crack time on the offline row
ExpectedPossible for shorter random strings: J0hn-Donnelly!1990 scores 4 yet shows 7 minutes on offline_fast_hashing_1e10_per_second. The 0–4 score is a coarse bucket; always read the specific crack-time row that matches your threat model rather than trusting the headline number alone.
Calling the tool via API instead of the browser
Transmitted by designThis slug is server-safe, so an API call sends the password in the request and the server runs zxcvbn (returning score, crackTime, feedback, guesses). That is fine for automated audits of test/synthetic passwords. For a password you actually USE, only the browser tool guarantees the secret never leaves your machine — the field is marked secret precisely so it is not logged.
Dictionaries are 2017-era (zxcvbn 4.4.2)
Known limitationzxcvbn 4.4.2 ships frozen word lists from its last release. A password riffing on a meme or breach from after that won't be flagged as common even if attackers now know it. The estimate is a strong lower bound on weakness, not proof of strength — never treat 'score 4' as a guarantee for an internet-facing account.
Trying to upload a file or password list
Not supportedThis is a text-only tool with a single password field — no file drop, no batch/CSV mode. To audit many secrets you would call the API per password. To hash or fingerprint a file instead, use multi-hash-fingerprinter; to measure the byte-level randomness of a file, use entropy-analyzer.
Frequently asked questions
Is my password really not transmitted?
When you use the browser tool, no. zxcvbn is plain JavaScript that runs in the page, and the password field is marked secret. Open DevTools → Network and type — you will see zero outbound requests carrying the value. The one exception is the API path: if you call the tool programmatically, the password is sent in the request so the server can score it. For a real password, stick to the browser tool.
What is a good zxcvbn score?
Score 4 is the goal — it means a very large guess count and 'centuries' on the throttled-online row, and usually offline-safe too. Score 3 is acceptable for accounts behind rate limiting but may be crackable offline if the hash leaks. Score 2 and below should be strengthened. Don't stop at the number though: read the specific crack-time row that matches your threat model.
Why does P@ssw0rd score lower than 'correct horse battery staple'?
Because zxcvbn scores guessability, not character variety. P@ssw0rd is one breach-listed common password with predictable @/0 substitutions, so it audits as score 0 / less than a second. correct horse battery staple is four uncommon words chained together — over 10^20 guesses, score 4 / centuries. Length and unpredictability beat symbol-juggling every time.
What do the four crack-time numbers mean?
They are the same password under four attacker speeds: online_throttling_100_per_hour (a rate-limited login), online_no_throttling_10_per_second (no rate limit / stuffing), offline_slow_hashing_1e4_per_second (a leaked database hashed with bcrypt/Argon2), and offline_fast_hashing_1e10_per_second (a GPU on an unsalted dump). The offline-fast row is the harshest and the one that exposes deceptively-weak passwords.
What is guesses_log10 and why should I use it?
It is the base-10 logarithm of the estimated guess count, so guesses_log10: 7.28 means roughly 19 million guesses. Because the 0–4 score is a coarse bucket, two passwords can both read 'score 4' while differing by many orders of magnitude. Comparing guesses_log10 between candidates is the precise way to tell which is actually stronger.
Does zxcvbn know about my name or email?
zxcvbn can take a user_inputs list (name, email, username) to penalise identity-based passwords, but this tool does not pass one — it audits the password in isolation. So a password containing your name won't be flagged as such here. Assume any password built from personal data is weaker than the score shows, and avoid them.
Does it support passphrases, emoji, and non-ASCII characters?
Yes. zxcvbn operates on the raw string, so spaces, long passphrases, accented letters, and emoji are all accepted. Unmatched characters fall into the bruteforce chunk, which is the part that genuinely adds entropy. Just check that the site you'll use it on actually accepts non-ASCII — some silently truncate or reject it.
Is this NIST-compliant?
zxcvbn predates NIST SP 800-63B but aligns with its core guidance: favour length and memorable passphrases over arbitrary composition rules, and screen against known-breached/common passwords. NIST also recommends checking new passwords against breach lists — zxcvbn's common-password dictionary does a lightweight version of that, though it is not a live breach lookup.
Why does a strong-looking random password still crack fast offline?
Length. A 10-char random hex string like 4f9a2c8e1b is pure bruteforce (score 3, centuries online) but only ~1 second on the offline-fast row because there simply aren't enough characters. For offline-safe randomness aim for 16+ random characters, or use a multi-word passphrase which reaches the same strength while staying memorable.
Can I audit a whole list of passwords at once?
Not in the browser tool — it has a single password field and no file/batch input. For bulk auditing you would script the server-safe API, one password per call (suitable for synthetic/test data, not live secrets). If your goal is hashing or comparing files rather than scoring passwords, use multi-hash-fingerprinter or file-integrity-monitor instead.
Are there file-size or tier limits?
No. This is a text-input tool — you enter a password string, not a file — so the security file-size caps (Free 10 MB / 1 file, Pro 100 MB / 5 files, and so on) simply don't apply. The auditor itself is on the Free tier and needs no sign-in.
Once a password passes, what should I do with it?
Generate and store the real secret in a password manager, then clear the input field — don't leave it sitting in the box or in clipboard history. For protecting files with a strong passphrase, use aes-256-encryptor (Web Crypto AES-GCM with PBKDF2). For signing messages with a key instead of a password, see pgp-message-signer.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.