How to audit a password with zero network requests — and prove it
- Step 1Open DevTools and switch to the Network panel — Before typing anything, press F12 (or right-click → Inspect) and select the Network tab. Leave it recording. This is your live proof that nothing is sent.
- Step 2Start typing your password and watch the panel — Type or paste a character at a time into the single
passwordfield. The Network panel stays empty of any request carrying the value — zxcvbn scores it in the page as you type. If a checker were exfiltrating it, you'd see a request here; you won't. - Step 3Read the report, all computed locally — The findings summary shows the 0–4 score and the four crack-time figures; the full zxcvbn JSON adds
guesses,guesses_log10, the matchedsequence, andfeedback. None of it required a server. - Step 4Act on the matched patterns — The
sequencearray names why it's weak —dictionary:passwords,repeat,spatial,date— andfeedback.suggestionsgives the fix (usually 'add another word', not 'add a symbol'). Adjust and re-audit; the Network panel stays quiet throughout. - Step 5Avoid the API path for real secrets — If you script this tool via its server-safe API, the password is sent in the request so the server can score it. That's fine for synthetic/test passwords but not for a real one. For anything you use, stay on the browser tool — the field is
secretprecisely so the value is never logged. - Step 6Clear the field when you're done — Once you've read the report, clear the input rather than leaving the password in the box or in clipboard history. To protect a real file with your audited passphrase, hand it to aes-256-encryptor, which also runs entirely in the browser.
Where your password goes: browser tool vs API path
The same slug has two paths. Only the browser tool keeps the value on your machine — this table is the whole privacy story.
| Aspect | Browser tool | Server-safe API path |
|---|---|---|
| Where scoring runs | In the page (zxcvbn JavaScript) | On the server |
| Is the password transmitted? | No | Yes (sent in the request) |
| Verifiable in DevTools → Network? | Yes — panel stays empty | n/a (you initiated the request) |
Field marked secret? | Yes (not logged) | Treated as secret server-side |
| Safe for a real, in-use password? | Yes | No — synthetic/test only |
| What you get back | Full zxcvbn JSON + summary | score, crackTime, feedback, guesses |
How to verify nothing was sent (DevTools checklist)
A repeatable check anyone can run. If any step shows a request carrying your password, stop using the tool.
| Step | What to do | Expected result |
|---|---|---|
| Open Network panel | F12 → Network, leave recording | Empty or only page-load assets |
| Type the password | Enter characters into the field | No new request appears for keystrokes |
| Filter to XHR/Fetch | Click the XHR/Fetch filter | No request body contains your value |
| Go offline mid-type | Disable network, keep typing | Scoring still works — it's all local |
Cookbook
These show the audit working entirely in-page — the Network panel stays empty throughout. Outputs are real zxcvbn 4.4.2; logs rounded, crack times verbatim from crack_times_display. The 'offline test' in the last example is the definitive proof.
Audit a real password with the Network panel open: nothing sent
Type a password you actually use while watching DevTools. The report appears with zero outbound requests for the value. This is the only safe way to score a live secret.
DevTools -> Network: recording, filtered to Fetch/XHR Type: <your real password> Observed network requests carrying the password: 0 zxcvbn report appears instantly, computed in-page: score: 3 guesses_log10: 9.8 crack_times_display.offline_fast_hashing_1e10_per_second: 11 minutes Proof: no request body ever contained your password.
The definitive test: go offline, keep auditing
Disable your network connection entirely, then keep typing. The score still updates. A tool that needed a server couldn't do this — it's hard proof the analysis is local.
Action: DevTools -> Network -> set to 'Offline' Then type: river otter velvet canyon Result: zxcvbn report still updates: score: 4 guesses_log10: 18.0 offline_fast_hashing_1e10_per_second: centuries Conclusion: no connectivity needed -> nothing was ever sent.
A weak password, scored privately: Summer2024!
Even auditing a weak password is done locally. You learn it's deceptively weak offline without ever exposing it to a server.
Input: Summer2024! (Network panel empty) score: 2 guesses_log10: 7.44 sequence: [ "dictionary:passwords", "bruteforce" ] offline_fast_hashing_1e10_per_second: less than a second online_throttling_100_per_hour: 31 years feedback.warning: "This is similar to a commonly used password"
What NOT to do: the server-safe API path sends it
If you call the tool's API programmatically, the password goes in the request. The server returns a trimmed report. Use this only for synthetic test passwords — never a real one.
POST (server-safe API) with body { password: "<test>" }
Server runs zxcvbn and returns:
{ score, crackTime, feedback, guesses }
WARNING: the password was transmitted in the request.
For a real secret, use the browser tool instead (field is 'secret').Iterating safely: strengthen without ever leaking a draft
Try several candidate passphrases in a row, watching guesses_log10 climb, all in-page. None of your drafts are sent anywhere.
Type: river otter -> guesses_log10 ~8, score 2 Type: river otter velvet -> guesses_log10 ~14, score 3 Type: river otter velvet canyon -> guesses_log10 ~18, score 4 Network panel throughout: no request carried any draft. Final password chosen and stored in a manager; field cleared.
Edge cases and what actually happens
Empty input — nothing typed
RejectedAn empty password field throws Enter a password to audit. and produces no report. There's no default or placeholder password — and nothing is sent for an empty field either.
Calling the tool via the server-safe API
Transmitted by designThis slug is on the server-safe list, so a programmatic API call sends the password in the request body and the server runs zxcvbn, returning score, crackTime, feedback, and guesses. That's intentional and fine for synthetic/test passwords. For a password you actually use, only the browser tool keeps the value local — the field is marked secret so it isn't logged.
Working fully offline (no internet connection)
SupportedOnce the page has loaded, you can disconnect and the auditor still scores passwords — zxcvbn is in-page JavaScript and needs no server. This is the strongest proof that nothing is transmitted: a tool that phoned home couldn't function offline.
Browser extensions or a corporate proxy intercepting traffic
Outside the tool's controlThe tool itself sends nothing, but a malicious browser extension, a keylogger, or a TLS-inspecting corporate proxy operates at a layer below the page and could capture keystrokes regardless. The Network-panel proof covers the tool's behaviour, not your whole device. Audit sensitive passwords on a machine you trust.
Password left sitting in the input field
Cleanup recommendedNothing is transmitted, but the value persists in browser memory and possibly clipboard history while it's in the box. Clear the field after reading the report, and avoid leaving the tab open with a real secret displayed.
Password contains your own name or email
Not detected herezxcvbn can take a user_inputs list to penalise identity-based passwords, but this tool passes none — it audits the password in isolation. So john1990 is scored against generic dictionaries, not flagged as containing your name. The privacy guarantee is unaffected; just treat personal-data passwords as weaker than the score implies.
Trying to upload a file to keep it private
Not supportedThis is a text-only tool with a single password field — no file drop. If your goal is to keep a file private rather than score a password, use a browser-side tool like aes-256-encryptor (Web Crypto, no upload) for encryption, or multi-hash-fingerprinter to hash a file locally.
Emoji or non-ASCII characters
Supportedzxcvbn operates on the raw string, so emoji and accented characters are accepted (counted as bruteforce) and scored locally with no error. As always, some login systems mangle non-ASCII on entry independent of how zxcvbn rates it.
Very long passphrase pasted from a manager
SupportedLength is handled fine and calc_time stays in single-digit milliseconds — all in-page, nothing sent. The score caps at 4; use guesses_log10 to see strength beyond the cap. Clear the field afterward.
Frequently asked questions
Is my password really not sent anywhere?
When you use the browser tool, no. zxcvbn is plain JavaScript that runs in the page, and the password field is marked secret. You can verify it yourself: open DevTools → Network, type, and watch — no outbound request carries the value. The single exception is the server-safe API path; if you call it programmatically the password is sent. For a real password, use the browser tool.
How do I prove the tool isn't transmitting my password?
Open DevTools (F12) → Network panel, filter to Fetch/XHR, and type your password. No request appears carrying the value. For an even stronger test, set the Network panel to 'Offline' and keep typing — the score still updates, which is only possible because the analysis runs entirely in your browser. A tool that phoned home couldn't work offline.
Can I use it with no internet connection?
Yes, once the page has loaded. Disconnect your network and the auditor keeps scoring passwords because zxcvbn is in-page JavaScript that needs no server. This is the cleanest demonstration that nothing is transmitted. If you reload the page while offline it won't fetch again, but a loaded tab keeps working.
Then why does the page mention a server-safe API?
Because this slug has two paths. The browser tool scores locally and sends nothing. The server-safe API path lets developers score passwords programmatically — and that path does send the password in the request, returning score, crackTime, feedback, and guesses. Use the API only for synthetic or test passwords; for a real secret, the browser tool is the private path.
Is it safe to check a password I'm actually using?
With the browser tool, yes — scoring runs in-page and the value never leaves your machine, which is the whole reason this tool exists. Verify it in DevTools if you want certainty. The only unsafe move would be routing a live password through the server-safe API, which transmits it; the browser tool does not.
Could a browser extension or proxy still capture my password?
Yes, but that's outside this tool's control. A malicious extension, a keylogger, or a TLS-inspecting corporate proxy operates below the web page and could capture keystrokes no matter what the tool does. The Network-panel proof covers the tool's behaviour only. For a sensitive password, audit it on a device and browser profile you trust.
Does it store or log my password anywhere?
No. The browser tool computes the score in memory and the password field is marked secret so it isn't written to logs. There's no account, no scoring telemetry on the value, and nothing persisted server-side from the browser path. Clear the input field when you're done so the value doesn't linger in the page or clipboard history.
Does it flag passwords built from my name or email?
Not in this implementation. zxcvbn can accept a user_inputs list to penalise identity-based passwords, but this tool passes none and audits the password alone. So a password containing your name isn't flagged as such here. This doesn't affect the privacy guarantee — just treat any personal-data password as weaker than its score suggests.
What exactly do I get back from the local audit?
The full zxcvbn JSON: the 0–4 score, raw guesses and guesses_log10, crack_times_display for four attacker speeds, the matched sequence (e.g. dictionary:passwords, spatial, date), and a feedback block with a warning and concrete suggestions. The findings summary highlights score, crack time, and feedback. All of it is computed in your browser.
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) don't apply. The auditor is on the Free tier and needs no sign-in.
Can I audit a file privately instead of a password?
Not with this tool — it only takes a password string. For private, browser-side file work, use aes-256-encryptor to encrypt a file locally (Web Crypto, no upload), multi-hash-fingerprinter to hash one in the browser, or entropy-analyzer to measure a file's byte-randomness.
What should I do after the audit?
Clear the input field so the password doesn't linger, then store the real secret in a password manager. To protect files with your audited passphrase, use aes-256-encryptor, and to sign messages with a key rather than a password, see pgp-message-signer — both run entirely in the browser.
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.