Online PDF tools ask for the file before explaining what they do with it. Someone who joins two pages of a contract, compresses a report, or extracts an image from a document hands sensitive material to a site they have just met.

A good share of those sites promises that the file does not leave the device. The promise can be true. The point is that it does not have to be accepted on trust: anyone can check, in their own browser, in about two minutes and without installing anything.

The procedure is described below and applies to any site that asks for a file, not only to the example measured at the end of the text.

Downloading the program and uploading the file are different events

A web page is a program that the browser downloads and runs inside your device. When the tool processes locally, what is downloaded is that program. The chosen file remains in the browser’s memory and the result comes back as a downloaded file.

When the tool processes on a server, the path is different. The file has to be uploaded, and uploading is a visible action: the page makes a network request carrying the content of the document.

It is that asymmetry that makes the check possible. Downloading a program and uploading a file are distinct events, and the browser records both on the same screen.

The procedure, in five steps

The screen in question is the Network tab of the developer tools, present in every computer browser. Chrome’s official documentation describes the panel as the record of the resources the page downloads and sends, and warns that it only records the activity that occurred while it is open. Firefox’s network monitor performs the same function and shows every request made by the page.

  1. Open the developer tools and go to Network. In Chrome and Edge, Ctrl + Shift + J (Cmd + Option + J on Mac) opens the panel; the Network tab is at the top. In Firefox, Ctrl + Shift + E (Cmd + Option + E on Mac) opens the network monitor directly.
  2. Reload the page with the panel open. The record does not recover what happened before you opened the tool.
  3. Clear the list immediately before choosing the file. The clear button leaves the screen empty, and everything that appears from then on belongs to the operation you are testing.
  4. Choose the file and run the operation until the result comes out.
  5. Read the lines that appeared. Each line is a request. What gives away an upload is a request with method POST or PUT whose size approaches the weight of the file you handed over. Clicking the line, the panel shows the method, the address, and the content sent.

What is often confused with an upload

Three things appear on the list and are not your file going out.

The first is a piece of the program itself, loaded at the moment. Many sites only download the engine that handles PDFs when you activate the tool, so as not to weigh down the first visit. That appears as a GET of a file ending in .js, and the size corresponds to the program, not to the document.

The second is advertising and audience measurement. These are requests to third-party domains, which keep existing even when the file stays on the device.

The third is the result itself coming back. Downloading is not uploading, and the difference appears in the method of the request and in the direction of the traffic.

On a phone, the Network tab is not available in ordinary browsers. The check is done on the computer, on the same site, and the result applies to the program that site delivers.

The method applied to a Brazilian case

Transparency: BRUP — Ferramentas Úteis is a project of the author of this blog. It is included here as a measured case, with the procedure open for the reader to repeat, and not as a recommendation.

On August 23, 2026, the site’s home page listed 46 tool pages, among PDF manipulation, image processing, text utilities, and calculators. The catalog announces processing in the browser. The question is whether the network confirms it.

The test was done on the tool that turns text into a PDF, with the Network tab open and cleared before the operation. With the lines of text pasted and document creation triggered, no upload request appeared. All the lines recorded were GET of static files from the site itself: pieces of the program, fonts, and styles. The check through the browser’s performance interface confirmed the same result, with zero network requests initiated by fetch or XMLHttpRequest.

Because the observation of the network proves only the moment observed, the modules that execute the operation were read next, one by one. None of them contains fetch, XMLHttpRequest, sendBeacon, or WebSocket. The only occurrence of fetch is in the compatibility polyfill generated by the bundler, whose function is to preload pieces of the program itself.

The engine that assembles the document is the pdf-lib library, served by the site itself in a file of approximately 421 KB. It identifies itself in the Producer field of the generated PDF, which offers a second independent check: just open the properties of the file produced and see who assembled it.

The free plan’s quota also stays on the device. It is recorded in the browser’s local storage, and the site’s privacy policy, updated on August 8, 2026, describes the limit of five operations every 24 hours and of 10 MB per file. The same document describes a temporary handoff of up to 60 seconds, in the browser’s local database, used when the file is delivered on the home page and the tool opens on another page.

What the check does not prove

A successful test applies to the tool tested, at that moment and in that version of the site. A program delivered by a web page can change with any update, and the check is not a permanent seal. A tool used frequently for a sensitive document deserves an occasional recheck.

The file staying on the device also does not make the visit anonymous. A page with advertising or audience measurement continues to inform third parties that someone was there, and the measured case loads advertising and measurement scripts. These are two independent questions: the document is not uploaded, the visit is known.

Finally, a limit kept in the browser is not a server barrier. A local quota exists for as long as the browser keeps it, which makes it a courtesy of use and not an access control.

When local processing is the right criterion

The procedure matters more in some situations than in others. A document with personal data, an amount, an address, or health information is the clear case: a contract, a pay stub, a report, a receipt, and an identity document. A recording with your voice is also sensitive material, as the guide on the AI cloned-voice scam shows.

For material that is already public, the difference is small. Compressing the photo of a product that is going to an online store does not change in nature by passing through a server.

It is worth remembering that “does not send the file” and “is safe” are not the same statement. Local processing settles the path of the document. It says nothing about the quality of the result, nor about the origin of the file you opened, a question that the measured case’s own policy records when it recommends caution with files of unknown origin.

This blog applies the same standard to what it publishes about itself: when it states that it uses neither a cookie nor a visitor identifier, the statement is written so that it can be checked by the reader, not only announced.

The promise of local processing is easy to write and hard to fake: it leaves a trace on the network. Checking costs two minutes and applies to any tool, including the ones this blog cites.

Sources

  • Record of every resource downloaded and sent by the page, the need to reload with the panel open, and the reading of the method, size, and content of the request — Chrome DevTools: Network panel (official documentation), verified on 2026-08-23.
  • Display of every request made by the page and the shortcut for opening the network monitor — Firefox DevTools: Network Monitor (official documentation), verified on 2026-08-23.
  • Local reading of a file chosen by the user and upload as a separate and explicit step — MDN: using files in web applications (official documentation), verified on 2026-08-23.
  • Catalog with 46 tool pages, absence of an upload request in the creation of the PDF, absence of network primitives in the modules of the operation, identification of the pdf-lib library, and size of the file that serves it — public extract of the measurement (own measurement), measured on 2026-08-23; the result applies to the tools and the version indicated in the extract.
  • Quota of five operations every 24 hours, limit of 10 MB per file, local handoff of up to 60 seconds, and recommendation of caution with files of unknown origin — BRUP privacy policy (the service’s own document), verified on 2026-08-23.
  • JavaScript library for PDF manipulation executed in the browser — pdf-lib (official repository of the project), verified on 2026-08-23.