Why our online tools never upload your files

No file you open in a tool on beeprotonai.info is sent to us or to anyone else. The conversion, the compression, the OCR, the merge — all of it happens inside the browser tab in front of you, using code your browser has already downloaded. You can prove it in about forty seconds: load the tool page, turn off your Wi-Fi, then process your file. It still works. That test is the whole argument, and the rest of this article explains why it works, what the alternative does with your documents, and where browser processing genuinely runs out of road.

What a normal online converter does with your file

The usual architecture is not sinister, it is just ordinary web engineering. You pick a file, the page sends it as a multipart HTTP POST, and a server writes it to a temporary directory. A worker process picks it up, runs a command-line tool over it, and writes the result somewhere a download URL can reach. Then a cleanup job deletes both, eventually.

Between those steps your document exists in more places than the page implies:

• The temporary file on the application server.
• The reverse proxy or load balancer in front of it, which may buffer the whole upload to disk before passing it on.
• Access logs, which record the file name even when the file itself is deleted.
• A CDN or object store, if the result is served from one.
• Whatever nightly backup runs across all of the above.
• The error tracker, if the job crashed halfway and somebody attached the input to a bug report.

A retention promise covers the first item honestly and the rest optimistically. None of this is unusual, and for a holiday photo none of it matters. For an Aadhaar scan, a salary slip, a client's bank statement or an unsigned contract, you have made a copy of a confidential document on infrastructure you cannot inspect, under a policy you did not read, in a jurisdiction you did not check. That is the actual risk, and it is a risk of copies existing, not of anyone being malicious.

What browser-local processing means

Four browser APIs do the work, and none of them involves a network request.

The File API hands JavaScript the bytes of a file you selected, as an ArrayBuffer, without uploading anything. The <input type="file"> element is often misread as an upload control. It is a read control. The upload only happens if the page then chooses to POST what it read, and ours does not.

WebAssembly is why the heavy formats are possible at all. A PDF or XLSX parser is thousands of lines of fiddly binary handling, and the mature ones are written in C++ or Rust. Compiled to WebAssembly, that same code runs in the tab at close to native speed. Every library the site uses is served from our own domain rather than a third-party CDN: pdf-lib and PDF.js for PDFs, SheetJS for spreadsheets, Tesseract for OCR, JSZip for archives, mammoth for Word files.

Web Workers run that code on a background thread. This is not a privacy feature, it is what stops the page freezing. PDF.js and Tesseract both spawn workers, which is why a 200-page render keeps a responsive progress bar instead of a white screen and a "page unresponsive" dialog.

Canvas and object URLs finish the job. Resizing, cropping, rotating and re-encoding an image are canvas operations. The result comes back as a Blob, and URL.createObjectURL() turns it into a blob: address that only your tab can resolve. Paste one into another browser and it resolves to nothing. Clicking Clear, or closing the tab, revokes it and the memory is freed.

The practical consequence: the tool page needs the network to load, and then it does not need it again.

Verify it yourself

Do not take a privacy page's word for this, including ours. Three checks, in increasing order of paranoia.

1. Airplane mode. Open Reduce Image Size in KB, wait for the page to finish loading, then disconnect from the network. Process your file and download the result. A tool that uploaded would fail here.
2. The Network tab. Press F12, open Network, filter to Fetch/XHR, then run the tool. You will see the tool's own request list stay empty. What you will see under JS is the library loading from /static/vendor/, once, the first time you use that tool.
3. Look at the code. Everything is plain JavaScript served unminified enough to read: /static/js/tools/image.js, pdf.js, excel.js, ai.js. Search for fetch( and XMLHttpRequest and see what the results are doing. This is a check you can run on any site that claims local processing, and the answer is usually not the one the marketing copy suggests.

Two tools pull a large file on first use, and it is worth knowing why so the download does not look suspicious. OCR needs a language model: roughly 32 MB of Tesseract data across fifteen languages, of which you fetch only the languages you ticked. Background removal needs a neural network, 40–80 MB depending on the quality setting. Both are downloads into your browser, cached for later runs. Nothing about your image goes out with them.

Where browser tools hit their limits

This is the part most "private online tools" pages leave out. Browser processing is not strictly better; it trades server capacity for privacy, and sometimes that trade is wrong.

There is a real second-order cost too: a 32 MB model download on a metered connection is not free, even if it is only once.

What we do collect

Local file processing does not make a site anonymous, and pretending otherwise would be dishonest. Here is the complete list, and it matches the privacy policy.

Page statistics, cookie-free. Our own first-party analytics records the page address, the referring site's domain, device type, browser and OS family, and a visitor code made by hashing your IP with your user agent and a salt that rotates every day. The raw IP is never stored, no cookie is set, and because the salt changes at midnight the same person on two days is two unlinkable codes. Kept for up to 13 months.

A tool-usage counter. When a tool finishes, the page sends one event containing the tool's slug and the page path — "reduce-image-size", nothing more. No file name, no size, no content, no result. It tells us which of the 81 tools to keep improving.

Server logs. IP address, browser and requested path, for security and debugging, like every web server.

Things you type into a form. Contact and quote forms, the newsletter, and the Client Portal. Those are data you chose to send.

Ad cookies, on content pages only. Ads run on tool, learn, roadmap, practice, resources and blog pages, through partners such as Google AdSense, and those partners may set cookies. Choosing Essential only in the cookie banner requests non-personalised ads. There are no ads inside the Client Portal. The ad script and the tool's processing share a page and nothing else: the ad frame has no access to the ArrayBuffer your file was read into, and there is no code path from one to the other. Our own cookies are three: csrftoken, sessionid and bp_consent.

So the honest summary is not "we collect nothing". It is: we count pages and tool runs without identifying you, we let an ad network set cookies on content pages, and your files are not part of any of it because they never leave your device.

Frequently asked questions

If nothing is uploaded, why does the page need internet at all? To download the page and its libraries once. After that a tool such as Merge PDF works offline, which is the simplest test that the processing is local.

Are the results stored in my browser after I leave? No. Outputs live in tab memory as blob: URLs and are revoked when you press Clear or close the tab. Nothing is written to localStorage or IndexedDB except your theme choice and roadmap checkboxes.

Can the ad script see my file? No. Ads load in a separate cross-origin frame with no access to the page's variables, and your file is only ever an in-memory buffer. The upload that would be needed to leak it does not exist in the code.

Is browser processing safe for something genuinely confidential? For a single file on a device you control, it removes the "a copy exists on someone's server" problem entirely, which is the main one. It does not protect you from malware on your own machine, from a shared or public computer, or from leaving the downloaded output in your Downloads folder on a laptop you then lend to someone.