Open an “online password generator,” click generate, then open the Network panel. If the request body or query string contains the password you just created, plaintext has already left the device. You do not have to trust a brand for that. The browser will show the traffic.
Keeping the work in the browser is not a slogan about decentralization. It shrinks the plaintext window to this machine: one less hop, one less server log, one less chance an operator reads a memory dump. Below: the threat model, steps you can check, and the limits. MyPassGen’s tools follow this rule. This piece is not a product tour. It answers one question: why sensitive work should not default to a server.
What a server-side compute widens
The plaintext window is every place plaintext (or a key that restores it) actually exists. When a server does the work, that window is rarely “the moment you clicked submit.” It is a chain that is hard to erase later:
- The TLS session from browser to origin — the server process sees a decrypted request, not ciphertext.
- Request-body samples in reverse proxies, WAFs, APM, and error trackers. One 500 can drop a form into a crash report.
- Query strings in application logs, slow-query logs, and access logs. Putting a key in
?key=writes it into the access log. - Intermediate files on databases, object storage, and scratch disks, plus backups and off-site copies.
- The time an operator, support agent, or attacker holds any of those copies. The window already happened. “We delete it after use” does not undo that.
Jurisdiction and subcontractors turn “we will not look” into a sentence you cannot audit. You can check the protocol and the traffic. You cannot check the other party’s internal runbook.
For password generation this is especially sharp: you want a secret that has never appeared in any system. If generation happens in someone else’s rack, the first copy is not yours. When you later paste it into production config, a CI variable, or a password manager, the leak surface already includes a node you cannot see.
The same applies to password audit. Submitting a reused password to a remote “strength check” hands your most sensitive passphrase to a third party. Public breach lookups can be designed with k-anonymity. MyPassGen’s Password Audit takes a harder constraint: the candidate is not uploaded. Entropy and the top leaked-password list both run in the browser. What you verify is not “they say they did not store it,” but that the request never contained the string.
For file encryption, “upload → encrypt on the server → download” means the passphrase and file contents existed in server memory. Local streaming encryption gives the server nothing useful: it does not even need to know whether you encrypted a photo or a disk image.
HTTPS is not local compute
TLS protects eavesdroppers on the path, not the server at the other end. When that server does the work, it is supposed to read plaintext. Local compute answers a different question: the other end should never see this material.
What “local” actually means
“Local” is easy to use as a slogan. Split it, or “visible only to you” on a drive starts sounding like local encryption.
A process on this machine, not “in some cloud account”
When MyPassGen says local, the work happens in your browser tab: random numbers from crypto.getRandomValues, symmetric encryption through the Web Crypto API. Key material lives in short-lived CryptoKey objects and is not sent as an analytics field. You can copy, export, or download the result. After the page closes, in-memory plaintext follows the browser lifecycle. A second copy is not kept on a remote host.
That is not the same as “drop the file into a private drive folder.” Drive servers can usually read object plaintext unless you sealed the file on this device first. Local-first asks: did plaintext ever exist in usable form outside this machine?
Algorithm and file limits are checkable facts
The only symmetric cipher is AES-256-GCM (authenticated encryption: a tampered ciphertext fails to decrypt). The file box streams one file at a time, up to 5 GB, and writes .lock (preferred) or .enc so a whole video is not loaded into memory at once. Those numbers are product constraints, not adjectives. If a page shows an algorithm switch that is not implemented, trust the product notes, not a guess.
Local describes where it runs. The tools open without an account
Where the work runs and “do I have to register” used to be written as two stories. On the current site, password generation, Password Audit, privacy tools, Burn-Link create, and the file box all open without an account. Local still only describes compute in the browser. It does not mean “plaintext can never leave the device” — Burn-Link briefly stores ciphertext on the server.
| Capability | Opens without an account | Is sensitive material uploaded by default? |
|---|---|---|
| Random / readable password generation | Yes | Not uploaded; generated in the browser |
| Password Audit | Yes | Candidate not uploaded; local strength + leaked list |
| Clean Link / redaction | Yes | URL and text stay local; not written to analytics |
| Burn-Link create | Yes | The upload is a ciphertext blob, not the original |
| Burn-Link read | Open to the recipient | Key in the URL # fragment; not sent with HTTP |
| File encryption box | Yes | File and passphrase not uploaded; streaming AES-256-GCM here |
Burn-Link is the only path that needs a short server stay, and what stays is ciphertext. The decryption key lives in the URL # segment: fragments are not sent with the HTTP request, so access logs usually show only the path. The reading page is public to the recipient — otherwise they would have to register first, and one-time sharing would fail. After the first read, ciphertext is burned by design. Server zero-knowledge does not mean “store nothing.” It means “stored data cannot be opened.” This piece only needs that rule in place.
Confirm with the Network panel that secrets did not leave
Slogans cannot prove themselves. The steps below do not depend on trust. Use the browser’s own developer tools. The goal is not to prove “there is no side channel anywhere.” It is to catch online tools that POST plaintext on a single click.
Start with the password generator. Open the generator page. Random characters and readable passphrases should generate immediately. This step checks whether generation leaves the device. Do not mistake a static-asset request for a password upload.
Open Network and enable Preserve log. Chrome, Edge, and Firefox all work. Filter Fetch/XHR first, then scan every request. Preserve log keeps the list if the page navigates. sendBeacon and Service Worker requests also appear in the panel.
Generate a password you can recognize. Make it long, copy it to a notes file, then paste that string — or a substring that will not appear in JS source — into the Network search box.
Check URL, Query, and Request Payload for a hit. If no request matches that substring, at least this generate click did not send plaintext as HTTP content. Unrelated strings in static scripts do not count. You are looking for the string you just created.
Repeat on the other tools. Open Password Audit, privacy tools, or the file box. Use a throwaway test password or a small file and search again. Audit should not send the candidate remotely. Cleaning should not POST the original. The file box should not upload plaintext as multipart.
On Burn-Link, watch ciphertext and the fragment. Create should send ciphertext, not the text you typed. In the full link the key sits after #. Drop the fragment and look at Network: the request path should not contain the key. The recipient opens the reading page without logging in.
What this proves, and what it does not
Network checks whether this action put plaintext into HTTP. It cannot see a same-origin script reading memory, a malicious extension, or a page already injected with XSS. That is enough to unmask a lot of “online tools.” It is not a formal proof.
What must stay local, and which exceptions to name
What must stay on this device is material you cannot take back once it leaves: a newly generated password, an old password under test, text waiting to be redacted, file plaintext, and symmetric keys. If those land in someone else’s log, deleting the page does not delete their copy.
What may leave the device is data that is cryptographically useless to the server: a Burn-Link ciphertext blob, and static assets that contain no secret. This site does not offer an account or a password vault. Do not confuse “the page requested a script” with “the tool uploaded plaintext.”
The file box output is a .lock / .enc you download. After that, a drive, USB stick, or email carries the ciphertext file. If you upload that ciphertext to a drive, the drive still cannot see the passphrase or the original — unless you put the passphrase in the same transfer or the same email. Local encryption changes “the drive admin can open your photos by default.” It does not change who is responsible for keeping the file.
Privacy tools (Clean Link and Data Redaction) also keep URLs and text in the browser: strip UTM / ad parameters, mask phones and ID numbers, then let you check the result before you send. The original is not uploaded and is not used as analytics event content. If a “clean” step POSTs the whole ticket to a server and returns “redacted,” the plaintext window already opened on the server. Redaction would be display only.
Limits and mistakes around browser-local encryption
Local-first reduces exposure on the server and on the path. It does not save a machine already owned by malware. Write the boundary into the expectation. That is more useful than printing AES in the footer.
If the page is injected, the algorithm cannot help
XSS or a hijacked script can read the input box. Web Crypto protects key operations on an honest page, not a malicious script that already shares the origin. You depend on same-origin policy, content security policy, and frontend supply-chain integrity. Seeing “AES-256-GCM” does not imply “therefore XSS is useless.”
Extensions, corporate proxies, shoulder surfing
Browser extensions and corporate SSL-intercept proxies can still see page content. When a company proxy injects a root certificate, the Network panel shows the world after the proxy. Lost devices, screen sharing, and shoulder surfing are out of scope for local compute. Those are endpoint problems. Keep them separate from “the server should not hold plaintext.”
“Not uploaded” is not “offline”
The page and its scripts still make requests. What you check is whether sensitive fields appear in those requests, not whether the ethernet cable is unplugged. MyPassGen also does not report the password under test, redaction originals, or file contents as analytics events. Events should not contain the secret itself.
Do not write the capability past the product
The first-version algorithm is AES-256-GCM. Do not expect a switchable RSA option or an undelivered national-cipher mode. Do not write the Burn-Link reading page as if it required registration. Do not claim the server can see plaintext or keys — that contradicts the product. An honest local-first sentence is: sensitive work finishes in the browser; plaintext, keys, and files are not uploaded by default; the burn-link server only stores ciphertext.
Where to start if you want to verify it yourself
If you only want to confirm that this generate click did not leave the device, start with the password generator: random characters and readable passphrases both finish here, and so do copy and export. Open Network and search the string you just created. That is the cheapest way to build an intuition for the plaintext window.
Common alternatives have specific limits. Plain email and chat leave keys in both histories, server archives, and device backups. Drives are readable to the server by default unless you encrypt on this device first. A key in a query parameter almost always lands in the access log. Those paths are not “less convenient.” The plaintext window is designed in.
To back up a file that should not sit on a drive in the clear, use the file encryption box: stream AES-256-GCM in the browser, one file up to 5 GB, download .lock or .enc. Capture the encrypt step and confirm the original file was not POSTed. To send a short secret once without putting the key in server logs, use a Burn-Link: encrypt locally, put the key after #, let the server touch only ciphertext, and let the recipient read without registering. This piece only asks you to answer: after this click, is the plaintext still in your tab?
MyPassGen’s line is “Local encryption, security that travels.” Traveling only works if the work happens in the tab you are looking at, and you can check that with the panel the browser already ships.