Slogans cannot be checked. Traffic can.
Many people judge an “online encryption” page by one sentence: computed locally, zero upload, end to end. Those words can sit on any site, including one that POSTs the file to a server and encrypts it there. They are not evidence.
What you can actually see is which requests this tab sends. The Network panel lists method, URL, query string, body, and some analytics. If the file name you just chose, the passphrase, or a canary only you know appears there, local encryption has already failed.
The reverse is narrower. A clean Network panel only shows that this run did not send those fields as business data. It does not prove memory holds no plaintext, that an extension did not read the clipboard, or that the next release will behave the same. The value is turning unverifiable copy into a repeatable observation.
What “local” actually means
“Browser-local” is not “this domain looks trustworthy.” It means encrypt and decrypt happen in the tab you are looking at. For AES-256-GCM, the usual correct path is the Web Crypto API: key derivation, encryption, and the auth tag all run in the browser’s crypto interface, instead of handing plaintext to a remote API.
A typical file flow is: you pick a local file, the script reads it as binary chunks in memory, encrypts each chunk, then the browser downloads the ciphertext. The .lock or .enc file is the result, not an upload receipt. A 5 GB single-file cap describes local streaming capacity, not a server that accepted 5 GB of plaintext.
Also separate “uploading your file” from “requests the page always makes.” A no-account tools site still loads CSS and scripts, and may send analytics with no message body. Those requests do not prove a file was uploaded. If an analytics query or body contains the passphrase you just typed, that is a different finding.
A checkable sentence beats adjectives: plaintext and keys for password generation, Password Audit, Privacy Cleaner, and file encrypt or decrypt stay in the browser by default; Burn-Link may send only ciphertext, with the decrypt key in the URL # fragment. MakePwd implements tools on that boundary, with no accounts. A promise is still a promise. Network turns it into a checklist.
Do not test with real keys, ID numbers, or unredacted spreadsheets. Use a disposable small file and a one-time long passphrase. You are checking traffic, not exposing privacy again.
A repeatable Network check
First pick a marker that will not appear in real work. Name the file canary-local-2026.xlsx, use a random long passphrase, and put one sentence in the body that exists only in this test. The canary is for search: paste it in the Network filter. A hit is a fail.
Open DevTools, switch to Network, enable Preserve log, and filter XHR / Fetch. Do not look only at successful requests—cancelled or 4xx calls may already have carried plaintext.
Then run a full action: pick a file, enter a passphrase, click encrypt or generate. Leave the panel open and check the three places below.
- Paste the canary in the filter first and look for a red hit. If you get one, stop and read that request. Do not keep judging by whether it “feels local.”
- If there is no hit, open each XHR / Fetch and compare the request line, query string, and body. Static assets, fonts, and scripts can be ignored.
- Filter analytics paths separately and open the query and body. Page titles and paths may appear. The passphrase you just typed, a password you checked, uncleaned source text, and file contents should not.
Read the request line
Read the path and the query after ? character by character. Locator fields such as id may appear. File names, passphrases, passwords under test, and the key after # should not. Compare the full address bar with the request line: if the part after the hash entered the request line, the implementation treated a fragment as a query, or a script read it and wrote it into a request.
Read the request body
POST / PUT payloads are the second place. If file encryption claims to finish locally, the body should not contain the original file bytes or the passphrase. Burn-Link may include a ciphertext field—that is expected outbound data; confirm it does not look like the text you just typed. If a Password Audit page POSTs the password, whether the purpose is written as “breach lookup” or “strength score,” it has already left the device.
Check analytics on their own
Analytics are easy to skip. A clean product API with an analytics hit that carries the full input still fails “plaintext stayed in the browser.” When you filter analytics paths, do not assume “the analytics script is harmless.” It is another outbound request, checked the same way as a product API.
Enable Preserve log. After encryption, a navigation or refresh can wipe the first request that carried plaintext if the box is unchecked, and you will get a false empty panel.
Queries go over HTTP. Fragments usually do not.
A URL has two parts people mix up. The query after the question mark enters the HTTP request line. Servers, reverse proxies, and access logs can see it. The fragment after the hash stays in the browser by default for the current page’s scripts and is not sent with that document request.
So if a one-time ciphertext link puts the key in #, opening s.html?id=...#key is designed so the server sees only id, not the key. That is not an extra crypto protocol. It is default fragment behavior. It has limits: paste the full address into a ticket, a group chat, or a redirect that drops the hash, and the key moves from “not in HTTP” to “on someone else’s screen and logs.”
The check is equally concrete: create a test Burn-Link and confirm the create request body has only ciphertext; open the reader and confirm the document request and later APIs contain only id. The part after # in the address bar should not appear in those requests. The reader is public for the recipient and needs no login.
| Where to look | Does it go over HTTP? | What counts as a pass |
|---|---|---|
| Page slogan | Not involved | Not evidence—use it only as contrast |
| Request line / query | Yes | No canary, no passphrase, no fragment key |
| POST body | Yes | No plaintext; Burn-Link may send ciphertext only |
URL # fragment |
Usually no | Present in the address bar, absent from the request line |
| Analytics | Depends on the build | No raw input-box text |
What you can prove, and what you cannot
The conclusion this check supports is narrow. Writing that limit down is more useful than stretching it.
It can support: in this browser, this version, and this action, plaintext, the passphrase, and the fragment key did not leave the tab as observed HTTP business data or analytics source text.
It cannot support: no other tab or extension is reading the clipboard; the Downloads folder is safe; the recipient will not screenshot ciphertext after decrypt; Password Audit covers every breach corpus. If the checker only does local entropy plus a public weak-password top list, it answers “does this look like a common weak password,” not “it never appeared in a breach.” That is not a web-wide HIBP check.
Do not treat it as a penetration test either. You did not inspect WebSockets or Service Worker caches, and you did not reverse obfuscated scripts. The goal is to tell a colleague: I opened Network, searched the canary, and the request line and body were clean. That is closer to an engineering discussion than forwarding “the site says nothing is uploaded.”
Use the same steps on MakePwd tools
If you want a page that writes the compute boundary clearly, start with MakePwd File Encryption Box. It opens with no sign-up. Pick a small file with no real privacy, use a canary passphrase, encrypt, and download a .lock. Watch Network: you should see static assets and maybe analytics, not the original file or passphrase as business fields. The site documents AES-256-GCM in Web Crypto, one file up to 5 GB.
Burn-Link is the second drill: create a harmless test string and confirm outbound data is ciphertext. The reader is public for the recipient; the link shape is s.html?id={id}#{key}. Password Audit is the drill for “does the input box enter analytics”—the password under test is not uploaded, and matching happens against a local list.
These drills do not prove any one site is “absolutely safe.” They make the same checklist familiar. On any page that claims local encryption, the steps stay: canary, Preserve log, request line, body, analytics.
Three things to remember next time
First, watch traffic, not slogans. Second, outbound ciphertext can be acceptable; keys and plaintext are not. Third, rerun the canary search after you change browser, version, or feature. Only a repeatable observation is worth writing into your own security notes.
If the next question is why a key can sit after the hash, that is the next note: how browsers handle URL fragments, and when that protection fails. This piece only turns “did plaintext leave this tab” into a check you can finish on the spot.