Open an “online password generator,” click Generate, then open DevTools → Network. If the request body or query string contains the password you just created, plaintext has already left your device. You do not need to trust a brand for this step. The browser will show the traffic.
Putting crypto in the browser is not a slogan about decentralization. It is a way to shrink the plaintext window: one fewer hop on the wire, one fewer server log, one fewer chance that an operator reads a memory dump. The rest of this article covers the threat model, a check you can run locally, and the limits of that check. PassAfer’s tools are built on this rule. This is not a product tour. It answers one question: why sensitive computation should not default to someone else’s server.
What a server-side round trip actually widens
The plaintext window is every place where plaintext — or a key that unwraps it — really exists. When the server does the work, that window is rarely “the moment you hit Submit.” It is a chain that is hard to erase after the fact:
- The TLS session from browser to origin — the server process sees a decrypted request, not ciphertext.
- Request-body sampling in reverse proxies, WAFs, APM, and error trackers. One HTTP 500 can dump a form into a crash report.
- Application logs, slow-query logs, and access logs. A key in
?key=is an access-log entry. - Databases, object storage, temp files on disk, plus backups and off-site copies.
- The interval in which ops, support, or an attacker can copy any of the above. “We delete it after use” does not rewind that interval.
Jurisdiction and subcontractors turn “we never look” into a sentence you cannot audit. What you can audit is the protocol and the traffic, not the vendor’s internal runbook.
For password generation this is especially sharp. You want a secret that has never appeared in any other system. If generation happens in someone else’s rack, the first copy is already not yours. Paste it into production config, CI variables, or a password manager later, and the leak surface already includes a node you cannot see.
The same logic hits password audit. Submitting a reused password to a remote “strength checker” hands a third party your most sensitive credential. Public breach lookups can be designed as k-anonymity protocols. PassAfer’s Password Audit takes a harder constraint: the password under test is not uploaded. Strength estimates and the comparison against a top leaked list both run in the browser. You are not verifying “they claim not to store it.” You are verifying that the request never contained the string.
For file encryption, “upload → encrypt on the server → download” means the passphrase and the file contents at least existed in server RAM. Local streaming encryption gives the server nothing readable to catch. It does not even need to know whether you encrypted a photo or a disk image.
HTTPS is not the same as local computation
TLS protects eavesdroppers on the path, not the server at the other end. If that server is doing the crypto, it is supposed to read plaintext. Local computation answers a different question: the other end should never see this material.
What “local” actually means
“Local” is easy to turn into marketing. Split it, or a cloud drive’s “only you can see this” will get sold as client-side encryption.
A process on your machine, not “in some cloud account”
On PassAfer, local means the work runs in your browser tab. Random bytes come from crypto.getRandomValues. Symmetric encryption uses the Web Crypto API, which browsers expose only in a secure context (HTTPS or localhost) and implement in native code rather than a JavaScript library you bundled yourself. Key material lives in short-lived CryptoKey objects and is not shipped out as an analytics field. You can copy, export, or download the result. Close the tab and the in-memory plaintext follows the browser’s usual lifetime — it is not kept as a second copy on a remote host.
That is not the same as “drop the file in a private cloud folder.” Object storage can usually read plaintext unless you sealed the file on your machine first. Local-first asks: did usable plaintext ever exist outside this device?
Algorithm and file limits are checkable facts
The first-release symmetric algorithm is AES-256-GCM only (authenticated encryption: if ciphertext is altered, decryption fails). File Encryption Box streams a single file up to 5 GB and writes .lock (preferred) or .enc, so a long video does not have to sit entirely in RAM. Those numbers are in the product spec, not adjectives. If a page shows an algorithm switch that has not shipped, treat the spec as source of truth.
Local is not “every tool is public”
Where the bytes are computed and who may use which tool are separate questions. Guests can generate random characters and passphrases, then copy or export them. Password Audit, privacy tools, Burn-Link create, File Encryption Box, and the vault unlock after sign-in. Reading “local” as “anyone can use everything” fights the permission matrix.
| Capability | Signed out | Sensitive material uploaded by default? |
|---|---|---|
| Random / passphrase generation | Available | Not uploaded; generated in the browser |
| Add to vault | Sign-in prompt | — |
| Password Audit | Sign-in prompt | Password under test is not uploaded; local strength + leak list |
| Clean Link / redaction | Sign-in prompt | URL and text stay local; not written to analytics |
| Burn-Link create | Sign-in prompt | The upload is a ciphertext blob, not the original text |
| Burn-Link read | Open to the recipient | Key lives in the URL # fragment; not sent with HTTP |
| File Encryption Box | Sign-in prompt | File and passphrase stay local; streaming AES-256-GCM |
Burn-Link is the only path that needs the server to hold something, and what it holds is ciphertext. The decryption key sits in the URL fragment. Per the URI spec, the fragment is not sent to the server with the HTTP request, so access logs usually show the path only. The read page is public for the recipient — otherwise they would have to register first, and one-shot secret sharing would not work. After the first read, ciphertext is designed to burn. Zero-knowledge on the server does not mean “store nothing.” It means “even stored, it cannot be opened.” This article only needs that contract.
Use the Network panel to see whether secrets left
Slogans do not prove themselves. The steps below need no trust relationship — only the browser’s own developer tools. The goal is not to prove “there is no side channel on earth.” It is to catch the common pattern: click once, POST the plaintext.
Start with the password generator; stay signed out. Random characters and passphrases should generate without an account. That separates “account traffic” from “did generation upload the password,” so a login request is not mistaken for a secret leak.
Open Network and tick Preserve log. Chrome, Edge, and Firefox all have this. Filter Fetch/XHR first, then scan all requests. Preserve log keeps the list if the page navigates. Watch for sendBeacon and Service Worker traffic as well.
Generate a password you can recognize. Lengthen it, copy it to a notes file, then paste the full string — or a substring that will not appear by chance in JS sources — into the Network search box.
Check URL, query, and request payload. If no request hits that substring, at least this Generate click did not put plaintext on the HTTP wire. Unrelated strings in static scripts do not count. You are hunting the string you just made.
Repeat after sign-in for the gated tools. Password Audit, privacy tools, and File Encryption Box need an account. Use a throwaway test password or a small dummy file. Audit should not send the password under test. Cleaning should not POST the original text. File Box should not multipart-upload the plaintext file.
For Burn-Link, inspect ciphertext and the fragment. Create (sign-in required) should send ciphertext, not the text you typed. In the full link, the key sits after #. Strip the fragment and look at Network: the request path should not contain the key. Recipients open the read page without signing in.
What this check proves — and what it does not
Network tells you whether this action put plaintext into HTTP. It cannot see a same-origin script reading memory, a malicious extension, or a page already altered by XSS. That is enough to unmask a large class of “online tools.” It is not a formal proof.
What must stay local, and which exceptions to name
Keep on the device anything that cannot be recalled once it leaves: a newly generated password, an old password under test, source text waiting to be redacted, file plaintext, symmetric keys. Once those sit in someone else’s log, deleting your tab does not delete their copy.
What may leave the device is data that is cryptographically useless to the server, or that belongs to the account system itself: a Burn-Link ciphertext blob, the username and login password needed to sign in, and static assets with no secrets. Do not conflate “sign in” with “upload the tool’s plaintext.” Sign-in is a permission gate — guests can generate passwords; audit, cleaning, Burn-Link create, File Box, and the vault unlock afterward. Login credentials travel on the account path. That is a different question from “did the newly generated password get uploaded.”
File Encryption Box writes a .lock / .enc file you download to disk. After that, a drive, USB stick, or email can carry the ciphertext. If you put that file on a cloud drive, the drive still cannot see the passphrase or the original — provided you did not put the passphrase in the same transfer or the same email in the clear. Local encryption changes “the storage admin can open your photos by default.” It does not remove physical custody.
Privacy tools (Clean Link and Data Redaction) also keep URLs and text in the browser: strip UTM and ad parameters, mask phone numbers and ID-like strings, then let you compare before you send. The original is not uploaded and is not used as analytics event content. If cleaning POSTed the whole ticket to a server and returned “redacted,” the plaintext window already opened on that server. Redaction would be a display layer.
Limits and mistakes around in-browser crypto
Local-first reduces exposure on the server and on the path. It does not save a laptop already owned by malware. Write the boundary into the expectation. Printing “AES” in a footer does less.
If the page is injected, the algorithm will not save you
XSS or a hijacked script can read input fields. Web Crypto protects key operations on an honest page, not a page where hostile script 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 harmless.”
Extensions, corporate proxies, shoulder surfing
Browser extensions and SSL-inspecting corporate proxies can still see page content. When a company proxy injects a root certificate, the Network panel shows the world after that proxy. Lost devices, screen share, and shoulder surfing are out of scope for local computation. Treat those as endpoint problems, separate from “the server should not hold plaintext.”
“No upload” is not “no network”
The page, its scripts, and sign-in requests still go out. You are checking whether sensitive fields appear in those requests, not whether you unplugged the cable. PassAfer also does not report passwords under test, redaction source text, or file contents as analytics events — the event must not contain the secret itself.
Do not write capabilities past the spec
First-release crypto is AES-256-GCM. Do not expect a switchable RSA mode or an undelivered national-algorithm option on the page. Do not describe the Burn-Link read page as login-gated. Do not claim the server can see plaintext or keys — that contradicts the product. Honest local-first copy is: sensitive work runs in the browser; plaintext, keys, and files are not uploaded by default; Burn-Link’s server only holds ciphertext.
Where to start if you want to verify it yourself
If you only want to know whether Generate sent anything, start on the password generator: no account, random characters and passphrases both finish on the device, copy and export included. Open Network and search for the string you just made. That is the cheapest way to feel what a plaintext window is.
The usual alternatives have concrete limits. Cleartext email and chat leave the key in both parties’ history, server archives, and device backups. A cloud drive is readable by the provider unless you encrypted first. A key in a query parameter almost always lands in access logs. Those paths are not “slightly less convenient.” The plaintext window is designed in.
If you need to back up a file you would not drop on a drive in the clear, sign in and encrypt a file: streaming AES-256-GCM in the browser, one file up to 5 GB, download .lock or .enc. Capture that session and confirm the original file was not POSTed. When you must send a short secret to a colleague once, and you do not want the key in server logs, use a self-destructing message: encrypt locally, put the key after #, let the server touch only ciphertext, and let the recipient open the read page without registering. This article only asks you to answer: after this click, is the plaintext still in your tab?
PassAfer’s line is “Local encryption, secure anywhere.” “Anywhere” only holds if the work runs in the tab you are looking at — and if you can confirm that with the panel the browser already ships.