How to passphrase or random string? compare them by guesses_log10
- Step 1Audit your candidate passphrase first — Paste the multi-word phrase you're considering (e.g.
river otter velvet canyon) into the singlepasswordfield. Note itsguesses_log10from the report — that one number is your baseline for the comparison. - Step 2Read which words zxcvbn recognised — Check the
sequencearray. Words in the dictionaries (common words, names, pop-culture) appear as cheapdictionarytokens; anything it can't match falls intobruteforce, which carries the real entropy. A phrase of four obscure words scores far higher than four top-1000 words. - Step 3Now audit your random string — Clear the field and paste the generated random password (e.g. a 16-char manager output). It will show as a single
bruteforcetoken. Note itsguesses_log10too — this is the other side of the comparison. - Step 4Compare the two guesses_log10 numbers directly — Higher wins, and each whole number is a 10× difference in guesses. If the passphrase is
18.0and the random string is19.2, the random string needs roughly 16× more guesses — but both are far past 'offline-safe', so either is fine in practice. - Step 5Use the crack-time rows to confirm on your threat model — If you fear an offline GPU dump, compare both candidates on
offline_fast_hashing_1e10_per_second. A short random string can lose to a long passphrase on this row even if its character set is wider — length and total entropy decide it. - Step 6Pick the winner, then store it properly — If memorability matters, a 4–5 word passphrase that audits score 4 with centuries on the offline-fast row is usually the better human choice. Generate or finalise the real secret in a password manager, clear the field, and for files protect them with aes-256-encryptor.
Passphrase length vs strength (zxcvbn 4.4.2)
Approximate guesses_log10 and offline-fast crack time as you add uncommon words. Exact values depend on how common zxcvbn finds each word; obscure words score higher than these.
| Passphrase | Words | guesses_log10 (approx) | offline-fast crack time | score |
|---|---|---|---|---|
otter | 1 | ~4 | less than a second | 0 |
river otter | 2 | ~8 | less than a second | 2 |
river otter velvet | 3 | ~14 | 5 hours | 3–4 |
river otter velvet canyon | 4 | ~18 | centuries | 4 |
river otter velvet canyon ember | 5 | ~22 | centuries | 4 |
Random string length vs strength (zxcvbn 4.4.2)
A generator's random output is pure bruteforce. Note how a short random string loses on the offline-fast row despite a wide character set.
| Random password | Length | guesses_log10 (approx) | offline-fast crack time | score |
|---|---|---|---|---|
4f9a2c8e | 8 hex | ~8 | less than a second | 2–3 |
4f9a2c8e1b | 10 hex | ~10 | 1 second | 3 |
gT7$km2!pQ | 10 mixed | ~14 | 3 hours | 3–4 |
gT7$km2!pQ9xLw | 14 mixed | ~20 | centuries | 4 |
gT7$km2!pQ9xLw#vR4 | 18 mixed | ~26+ | centuries | 4 |
Head-to-head at the same memorability cost
What you can comfortably remember (passphrase) versus what you'd store in a manager (random). Both reach offline-safe; the passphrase is the human-friendly route.
| Candidate | Type | Memorable? | guesses_log10 | Verdict |
|---|---|---|---|---|
correct horse battery staple | 4-word passphrase | Yes | 20.33 | Offline-safe, easy to recall |
gT7$km2!pQ9xLw | 14-char random | No (needs a manager) | ~20 | Offline-safe, must be stored |
Tr0ub4dour&3 | leet single word | Sort of | 7.28 | Crackable offline — avoid |
Cookbook
Audit each candidate in turn and compare the guesses_log10. These are real zxcvbn 4.4.2 outputs; logs are rounded and crack times are the verbatim crack_times_display strings. The recurring lesson: total entropy (length × unpredictability) decides it, not character variety.
The canonical passphrase: correct horse battery staple
Four uncommon words, no digits or symbols. zxcvbn pushes the guess count past 10^20 — your baseline for any comparison. This is what a strong human-memorable secret looks like.
Input: correct horse battery staple zxcvbn report (abridged): score: 4 guesses_log10: 20.33 sequence: [ dictionary, bruteforce, dictionary, ... ] crack_times_display: online_throttling_100_per_hour: centuries offline_fast_hashing_1e10_per_second: centuries feedback.warning: "" (nothing to fix)
A 14-char random string for comparison: gT7$km2!pQ9xLw
Pure bruteforce, wide character set, fully offline-safe — but you can't memorise it. Its guesses_log10 lands near the four-word passphrase, confirming both are strong; the difference is whether you store it or remember it.
Input: gT7$km2!pQ9xLw zxcvbn report (abridged): score: 4 guesses_log10: 20.0 sequence: [ "bruteforce" ] crack_times_display: online_throttling_100_per_hour: centuries offline_fast_hashing_1e10_per_second: centuries Takeaway: ties the passphrase on strength; loses on memorability.
Where 'random' fails: a 10-char hex string 4f9a2c8e1b
Random, yes, but too short. It's one bruteforce token at guesses_log10 ~10 — centuries online but only ~1 second offline. A four-word passphrase beats it decisively on the offline row.
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 Takeaway: short random < long passphrase. Length matters.
Three words isn't quite enough: river otter velvet
A three-word phrase reaches score 3–4 but the offline-fast row is only hours, not centuries. Watch guesses_log10 jump when you add the fourth word — that's the threshold for offline safety.
Input: river otter velvet zxcvbn report (abridged): score: 3 guesses_log10: 14.0 sequence: [ dictionary, bruteforce, dictionary ] crack_times_display: online_throttling_100_per_hour: centuries offline_fast_hashing_1e10_per_second: 5 hours Add a 4th uncommon word -> guesses_log10 ~18, offline-fast -> centuries.
Common words drag a phrase down: password love dragon star
Four words, but all of them are top common passwords or dictionary staples. zxcvbn scores each cheaply, so the phrase lands far below an obscure-word phrase of the same length. Word choice matters as much as word count.
Input: password love dragon star zxcvbn report (abridged): score: 2 guesses_log10: 9.0 sequence: [ dictionary:passwords, dictionary, dictionary, dictionary ] crack_times_display: online_throttling_100_per_hour: centuries offline_fast_hashing_1e10_per_second: less than a second Takeaway: pick UNCOMMON words; four common words != strong.
Edge cases and what actually happens
Empty input — nothing to compare
RejectedAn empty password field throws Enter a password to audit. and returns no report. You audit one candidate at a time, so compare by entering each in turn and reading off its guesses_log10.
Both candidates show score 4 and you can't tell them apart
ExpectedThe 0–4 score is a coarse bucket, so a four-word passphrase and a 30-char random string both cap at 4. Don't compare on the score — compare on guesses_log10. Each whole number of difference is a 10× difference in guesses; that's how you rank two 'score 4' candidates.
Passphrase words are all common dictionary words
By designIf your phrase is password love dragon star, zxcvbn matches each word to a cheap dictionary token and the total guesses_log10 stays low despite four words. Word count alone doesn't make a passphrase strong — choose uncommon words so more of the phrase falls into the high-entropy bruteforce chunk.
Spaces between words
Supportedzxcvbn operates on the raw string, so spaces are kept and counted. A spaced passphrase and the same phrase with no spaces score similarly because zxcvbn matches the words regardless. Just confirm the site you'll use it on accepts spaces — most do, but some trim or reject them.
Short random string loses to a long passphrase
ExpectedA 10-char random string is pure bruteforce but its guesses_log10 (~10) is below a four-word passphrase (~18). 'Random' doesn't mean 'strong' if it's short — for an offline-safe random secret aim for 16+ characters, or use the passphrase route.
Adding numbers/symbols to a passphrase
Minor effectAppending ! or a year to a strong passphrase barely moves guesses_log10 — zxcvbn treats a trailing digit/date as a cheap token. The gain from one more uncommon word dwarfs the gain from a symbol. Add words, not punctuation, to strengthen a phrase.
Emoji or non-ASCII in either candidate
Supportedzxcvbn accepts emoji and accented characters; unmatched ones fall into bruteforce and add entropy. No error is thrown. Be aware some login systems mangle non-ASCII on entry regardless of how zxcvbn rates it, which can break a strong-looking password in practice.
Comparing via the API instead of the browser
Transmitted by designThe slug is server-safe, so an API call sends each password to the server, which returns score, crackTime, feedback, and guesses (note: the API omits guesses_log10 — take log10 of guesses yourself). Fine for comparing synthetic candidates programmatically; for passwords you'll actually use, the browser tool keeps the value on your device.
Very long passphrase (50+ characters)
SupportedLength is handled fine and calc_time stays in single-digit milliseconds. The score caps at 4, but guesses_log10 keeps climbing, so a 5-word phrase and an 8-word phrase both read score 4 while the log shows the (large) difference. Use the log, not the score, to see the gain from extra words.
Frequently asked questions
Is a four-word passphrase really as strong as a random password?
Often yes — if the words are uncommon. correct horse battery staple audits at guesses_log10 ≈ 20, which ties a roughly 14-character mixed random string. The catch is word choice: four common words like password love dragon star score far lower. Compare the guesses_log10 of your specific phrase against your random candidate to see the real answer for your words.
How do I compare two passwords when both show score 4?
Use guesses_log10, not the 0–4 score. The score is a coarse bucket that caps at 4, so two very different passwords can both read 4. guesses_log10 is the base-10 log of the estimated guess count, so a candidate at 22 needs roughly 100× more guesses than one at 20. Audit each in turn and compare the logs directly.
How many words does my passphrase need?
Four uncommon words typically reaches score 4 with centuries on the offline-fast row (guesses_log10 ≈ 18–20). Three words often stalls at hours offline. Audit your phrase and watch guesses_log10 and the offline_fast_hashing_1e10_per_second row — add words until the offline-fast time is 'years' or 'centuries'. Obscure words let you stop sooner.
Why does my short random password crack so fast offline?
Length. A 10-char random string like 4f9a2c8e1b is pure bruteforce (centuries online) but only ~1 second on the offline-fast row because there simply aren't enough characters to outrun 10 billion guesses/second. For offline safety, use 16+ random characters or switch to a multi-word passphrase, which reaches the same strength while staying memorable.
Does adding numbers and symbols to a passphrase help much?
Barely. zxcvbn treats a trailing digit, year, or ! as a cheap token, so appending them moves guesses_log10 only slightly. Adding one more uncommon word gains far more entropy than any amount of punctuation. If you want a stronger phrase, add words rather than symbols.
Why did my four-word passphrase score low?
Probably because the words are common. Check the sequence array — words zxcvbn recognises appear as cheap dictionary tokens (especially dictionary:passwords), and four common words can total a low guesses_log10. Swap in obscure words so more of the phrase falls into the high-entropy bruteforce chunk, then re-audit.
Can I see both passwords side by side?
No — the tool has a single password field and audits one candidate at a time. Compare by auditing the passphrase, noting its guesses_log10, then auditing the random string and noting its log. There is no batch or split view in the browser tool.
Are spaces in a passphrase a problem?
Not for zxcvbn — it keeps and counts spaces, and a spaced phrase scores about the same as the unspaced version because it matches the words either way. The real risk is the destination site: some login forms trim leading/trailing spaces or reject internal ones, which can silently change your password, so test that the service accepts spaces.
Does the comparison work with emoji or accented words?
Yes. zxcvbn operates on the raw JavaScript string, so emoji and accented letters are accepted and counted as bruteforce characters it can't dictionary-match, which adds entropy. They don't cause errors. Just remember some systems mangle non-ASCII on entry, so a strong-looking emoji password may break in practice.
Does the API give me guesses_log10 for scripted comparisons?
The API returns score, crackTime, feedback, and guesses — but not guesses_log10 directly. Compute it yourself as log10 of guesses. The browser tool exposes the full zxcvbn JSON including guesses_log10. For real passwords use the browser tool; the server-safe API is best for synthetic comparison sets.
Are there file-size or tier limits?
No. This is a text-input tool — you paste 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) don't apply. The auditor is on the Free tier and needs no sign-in.
I've picked a winner — what next?
Finalise the secret in a password manager and clear the input field rather than leaving it in the box or clipboard. To protect files with your chosen passphrase, use aes-256-encryptor (Web Crypto AES-GCM with PBKDF2 100k). To measure the raw byte-randomness of a generated key file rather than a password, see entropy-analyzer.
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.