# Why password.es never sends your password anywhere

> A site that asks for your password in order to check it has a trust problem no promise can fix. Our answer isn't a better promise: it's not needing the password at all, and letting you verify that yourself in thirty seconds.

2026-07-15 · David Carrero · password.es
Original: https://password.es/en/blog/why-password-es-never-sends-your-password/

---

Typing "we don't store your password" onto a web page costs exactly what typing
anything else costs: nothing. **It's a sentence, not a guarantee.** The people
telling the truth write it and the people lying write it, and from your side of
the screen the two look identical.

That's the underlying problem with any site that asks for a password so it can
"analyse" it. Even if the service is spotless — clean code, good intentions,
decent people — you have no way of knowing. The server is a closed box. You hand
over the most sensitive thing you own and trust that what happens on the other
side is what you were told happens.

And there's a detail that tends to get skipped: **a promise not to store
something doesn't protect you from the things that aren't up to the person
promising.** An honest server can still have logs nobody ever reviewed, a proxy
in the middle, an automatic backup, a new hire, or simply a bad day. The password
has already left your machine. Whatever happens next is out of your hands and,
quite often, out of theirs too.

## The only answer that doesn't ask you to believe anything

The fix isn't a better promise. It's **not needing the data**.

If your password never leaves the browser, the question "what do they do with
it?" stops meaning anything. There is no "they". There's no server receiving it,
no log it turns up in, no backup holding it, no employee who could read it. Trust
isn't managed better here: it's removed from the problem.

That's what [password.es](/en/) does. The [checker](/en/checker/) analyses what
you type inside your own browser, on your own processor. The text you type
doesn't travel anywhere because there's nowhere for it to travel to.

## Where the randomness comes from

The [generator](/en/) works on the same principle. Making a random password
requires randomness, and there are two ways to get it: ask a server, or ask the
browser. **Asking a server would be absurd: the server would know your password
before you did.**

So we ask the browser, with `crypto.getRandomValues()`. It's the web platform's
standard API for cryptographic randomness — the one that exists for precisely
this purpose, as opposed to `Math.random()`, which is fine for shuffling a deck
in a card game and useless against anyone who actually cares. The randomness is
produced by the browser itself, on your machine. We take no part in it: the
result appears on your screen and stays there.

## How to check this without taking my word for it

Everything above is still, for now, a paragraph written by the same people who
built the site. Which is to say: exactly the kind of thing I've just told you to
distrust. So don't believe me. **Look.**

Open your browser's developer tools — `F12`, or `Cmd+Option+I` on a Mac — go to
the *Network* tab, leave it open and load the checker. You'll watch the page come
in. Now clear the list, click into the password field and type.

Here's what you'll see, and this is a moment for accuracy rather than salesmanship:

- **Clicking into the field fires one request.** It isn't your password — you
  haven't typed anything yet — it's the library that does the analysis, a file
  called `zxcvbn-en.min.js` carrying the word lists, names, keyboard patterns and
  known passwords it compares against. It downloads from password.es the moment
  you touch the field, so it arrives while you're still typing. Same domain,
  static file, identical for everyone who opens this page — the site has a
  version per language, and this one pulls the English list.
- **After that, type whatever you like: the list sits still.** One letter,
  twenty, delete it, start again, paste in a long block of text. Zero requests.
  The counter doesn't budge. The dictionary is already in your browser and the
  lookup happens against your own machine's memory.

That distinction is the whole thing. **It's not that you're trusting the request
not to carry your password: it's that there is no request.** You don't have to
interpret anything or read a line of code; you just have to watch a counter that
never goes up.

## The full inventory, warts and all

Since the whole argument is "go check", it would be odd to hide what you'd find
when you did. The honest inventory of password.es:

**There's no analytics.** No Google Analytics, no tasteful alternative, no pixel.
There was one and it was pulled from every page. **There are no cookies.** The
site sets none. There is one thing kept in your browser: whether you prefer the
light or dark theme, in local storage on your own device. It's never sent
anywhere and you can delete it from that same inspector. **There's no signup, no
accounts, no forms**: there's nowhere to leave a piece of data even if you wanted
to.

And the wart, because there is one: **the page requests two typefaces from
Google's servers when it loads.** That means Google can see that someone with
your IP loaded a page on this domain, as on an enormous number of sites. It
doesn't see what you type — that request happens earlier and never repeats — but
it is a third-party request, you'll see it in that same *Network* tab, and it
would make no sense to tell you to open the inspector and then not mention it.
It's on the list of things to fix.

## Why we're telling you this

We could have written "zero requests, total privacy" and left it there. It would
have sounded better and it would have been false in the details: there's a
dictionary request and there are some fonts. **An argument that collapses the
moment someone checks it was never an argument: it was advertising.**

The precise version is less tidy and it survives scrutiny: what you type doesn't
leave your browser, and you can see that in thirty seconds with a tool you
already have installed.

And this comes back to you as a general rule. **Next time a website asks for your
password for any reason at all, open that tab and watch for a request when you
press a key.** If one shows up, your password is gone. It doesn't matter what the
privacy notice says, how reassuring the little padlock on the form looks, or how
serious the company seems. And if a site shows you your analysed password after a
spinner has turned, you already know where it went.

The least-discussed rule in security isn't about passwords at all: it's about
verification. Trust is fine. **Checking is better, and here it's free.**

---

*Sources: the architecture of password.es itself, verifiable with any browser's
inspector — on field focus the checker downloads the analysis library and its
word lists (`zxcvbn-en.min.js`) from its own domain, and issues no request while
you type · `crypto.getRandomValues()`, the Web Crypto API standard for
cryptographic randomness · the site's code contains no analytics, pixels or
cookies; the only thing stored locally is the theme preference · the typefaces
are served from Google Fonts.*