How to Check a PDF Tool Doesn't Upload Your Files

01 / The problem

Why "we don't upload your files" isn't enough

A privacy promise on a web page is marketing copy. It can be honest and still be wrong in ways that matter to you:

Some features need a server. A site can do simple jobs in the browser and quietly send harder ones (OCR, Word conversion, heavy compression) to a server.
Local processing doesn't rule out other traffic. A tool can process your PDF on your device and still send the file name, page count or usage events to an analytics service.
Websites change with every deploy. What was true when someone wrote the privacy page may not be true of the code your browser runs today.
Third-party code runs with the page's permissions. Ad, analytics and chat scripts can read anything on the page.

What you can check is what your browser actually sends. Every request a web page makes goes through the browser, and every desktop browser can show you that list. You don't need to read the code, and you don't need to trust us.

What this test can and can't prove. The Network panel shows the requests made by the tab you are watching, at the time you watch. It can't promise how the site will behave after its next update, and it can't see other apps on your computer. Repeat the check when it matters, and always test with a harmless file first.

02 / Paperfoundry, specifically

How Paperfoundry handles your files

We read our own page code to confirm this, then tested every tool (see results). Paperfoundry has no upload endpoint. When you choose a file, the browser reads it into the tab's memory using the standard File API. From there:

Images to PDF, Merge, Extract pages and Compress (text-preserving) use pdf-lib, an open-source JavaScript library that runs in the tab.
PDF to images and Compress (smaller scanned copy) also use Mozilla's PDF.js to draw each page onto a canvas. PDF.js runs part of its work in a Web Worker, a background thread inside your browser that we load from our own domain.
The finished file becomes a blob: link, which points to memory inside your browser, and your browser saves it to your downloads folder.

Every request a Paperfoundry tool page makes

When	What	Sent to	Your file in it?
Page opens	The page, its stylesheet and main script (about 16 KB each), and the icon	pdfnook.net	No
Page opens	A font stylesheet plus the DM Sans and Manrope font files (two files in our test)	fonts.googleapis.com fonts.gstatic.com	No Google receives your IP address, browser details and our site's address. It does not receive file names or content.
Page opens	`analytics.js`, a consent-based analytics script shared across Toolwoven sites	pdfnook.net	No It only runs on toolwoven.com addresses. On pdfnook.net it stops on its first line, so Google Analytics is not loaded and no consent banner appears.
Page opens	`account.js`, the optional "Sign in" button	pdfnook.net	No When you're not signed in it makes no further requests (confirmed in our test).
First time you run a tool in a tab	The PDF code: pdf-lib (about 430 KB). PDF to images and the scanned-copy compression also load PDF.js (about 540 KB) and its worker (about 1.3 MB)	pdfnook.net	No These are plain downloads of code (`GET`, no request body).
Only if you choose to sign in	Sign-in link, session refresh, subscription status	rmwncsegjusfzlyefbct.supabase.co	No These requests carry your email address, a session token and the site name. They contain no file names or file content. (We read this from the code but did not test a signed-in session.)
Never	Any `POST` or `PUT` containing your document, its name, its text or its page images	—	Never

The honest caveat: Google Fonts. Our tool pages load their typefaces from Google's font service. That request goes to Google whether or not you use a tool. It contains no document data, but Google does see that a browser at your IP address opened a Paperfoundry page. If that matters for your threat model, block fonts.googleapis.com with a content blocker. The tools work without it. This guide page loads no third-party resources at all.

03 / Check it yourself

Check with your browser's Network panel

The method is the same in every browser. Open the tool, open the Network panel, keep the log, clear it, then use the tool with a test file and read what appeared.

Use a harmless test file. Pick a PDF you wouldn't mind leaking, such as a one-page document you write yourself. Note its size, for example 240 KB.
Open the tool page, then open the Network panel (shortcuts below).
Turn on log preservation so requests stay listed if the page reloads or navigates. Then clear the list.
Use the tool: choose the file, run it and download the result.
Filter to script requests (Fetch/XHR) first. These are how a page sends data in the background. Then switch back to All to see everything else.
Look for anything that sends data: add the Method column and look for POST or PUT. Click any suspicious row and open its payload or request body. An upload shows up as a request whose sent size is close to your file's size, often with Content-Type: multipart/form-data.

Read the size columns carefully. In Chrome the Size column is the size of the response (what came back), not what was sent. To see what was sent, open the request and check its payload, or the content-length request header. blob: and data: rows are memory inside your browser, not network traffic.

Practise on this page first

This guide page loads only itself and its icon. Open your Network panel, clear it, then try both buttons. The first reads a file locally and should add no rows. The second deliberately sends a short piece of dummy text to our server, so you can see what a real upload row looks like.

Choose any file (stays here) ↥

Nothing yet. Your file is never sent anywhere by the first button.

Google Chrome (and Edge, Brave, Opera) Chrome DevTools

Open DevTools: Cmd+Option+I on Mac, Ctrl+Shift+I or F12 on Windows and Linux. You can also use the ⋮ menu, then More Tools › Developer Tools. Click the Network tab.
Tick Preserve log in the Network toolbar. Then click the clear button (⊘).
In the filter bar, click Fetch/XHR. Also check WS, because WebSockets can stream data too. Finish on All.
Right-click any column header and turn on Method.
Click a request. The Headers tab shows its Request Headers, including content-length. The Payload tab appears only when the request sends data or query parameters, and shows exactly what was sent.
For the offline test: in the Network throttling drop-down (next to Disable cache, normally showing No throttling), choose Offline.

Official docs: Open Chrome DevTools · Network features reference. Labels checked against these pages on 19 Oct 2026. Chrome sometimes regroups toolbar items, so if a label has moved, search that reference page for it.

Mozilla Firefox Network Monitor

Open the Network Monitor directly: Cmd+Option+E on Mac, Ctrl+Shift+E on Windows and Linux. From the menu bar: Tools › Browser Tools › Web Developer Tools, then the Network tab.
Open the menu of other actions (the gear icon at the right end of the Network toolbar) and turn on Persist Logs. Clear the list with the toolbar's bin icon.
Use the type buttons: XHR for background requests, WS for WebSockets, then All.
The Method, Transferred and Size columns are available. Right-click a column header to add or remove columns.
Click a request. The Request tab shows the body that was sent, and Headers shows Content-Length.
For the offline test: open the Throttling menu in the toolbar and choose Offline.

Official docs: Network Monitor · Network Monitor toolbar · Request details · Throttling. Checked 19 Oct 2026.

Apple Safari (Mac) Web Inspector

Turn on the developer tools once: Safari › Settings… › Advanced, then tick Show features for web developers.
On the tool page press Option+Cmd+I (or Develop › Show Web Inspector), then open the Network tab.
Tick Preserve Log. Then clear the list.
Use the resource type buttons above the table. XHR/Fetch shows background requests, and All shows everything.
Right-click the table header and tick Method.
Select a request. In Headers, look for a Request Data section, which only appears when something was sent. The Sizes panel lists Bytes Sent (headers and body) separately from Bytes Received.
For the offline test: Safari's Web Inspector has no offline switch, so turn off Wi-Fi or unplug the network cable instead.

Official docs: Enabling Developer Features (Apple) · Enabling Web Inspector · Network Tab. The labels XHR/Fetch, Request Data and Bytes Sent were checked in WebKit's Web Inspector source on 19 Oct 2026.

04 / Pull the plug

The offline test

If a tool still works with no network at all, the processing can't be happening on a server. It is the simplest check to explain to someone else.

Open the tool page while online.
Run the tool once with a dummy file. On Paperfoundry this matters, because the PDF code is downloaded the first time you use each tool, not when the page opens.
Go offline: use the browser's Offline setting (above), or turn off Wi-Fi.
Without reloading, choose your file and run the tool again. If you get a download, the work happened on your device.
Before reconnecting, keep the Network panel open with log preservation on. A tool could, in theory, store data and send it once you are back online, and this is how you would catch it.

Paperfoundry offline results

Tool	Offline straight after the page loads	Offline after one online run in the same tab	Code fetched on first use
Images to PDF	Fails "Failed to fetch dynamically imported module"	Works	pdf-lib, about 430 KB
PDF to images	Fails same message	Works	pdf-lib, PDF.js and its worker, about 2.2 MB
Merge PDFs	Fails same message	Works	pdf-lib, about 430 KB
Extract PDF pages	Fails same message	Works	pdf-lib, about 430 KB
Compress PDF: preserve text	Fails same message	Works	pdf-lib, about 430 KB
Compress PDF: smaller scanned copy	Fails same message	Works	pdf-lib, PDF.js and its worker, about 2.2 MB

The failures straight after loading are a download-timing issue, not an upload: the tool hadn't fetched its own code yet. Paperfoundry doesn't install a service worker, so it has no offline mode. If you reload the page while offline, it won't load.

05 / Any site, any tool

How to check any online file tool

You can use the same routine on any website that handles documents, photos or audio, including ours after future updates. It works for training sessions too: give each person a dummy file and have them fill in the list.

Start clean. Use a private window or a browser profile with no extensions. Extensions make their own requests, and those show up as noise.
Make the test file recognisable. Give it an unusual name and size, such as canary-test-7Q2.pdf at 300 KB. An upload is much easier to spot when you know exactly what to look for.
Watch the whole journey. Keep the log, then record what happens when you choose the file, when you press the button and when you download. Some services upload as soon as you drop the file in.
Look for POST, PUT and WebSocket traffic. Check the sent size, the payload and multipart/form-data. Also look for large requests to cloud storage hosts: names containing storage, upload, s3 or blob.core are common.
Separate "uploads" from "third parties". Fonts, analytics and ads don't usually carry your file, but they do tell another company you visited. Note both, and judge them differently.
Run the offline test. If the tool still works offline, the file wasn't processed on a server. If it fails offline, it may only have needed to download code, as Paperfoundry does on first use. Check the Network panel to see which.
Read the result, not the badge. Note the browser, the date and what you saw. A result only applies to the version of the site you tested.
When it matters, re-test. Before you put a sensitive file through any web tool, repeat the check. It takes about two minutes.

06 / Our measurements

Our test results, tool by tool

We tested the published version of each tool with Google Chrome 155 in headless mode, driven through the Chrome DevTools Protocol, which is the same data source the Network panel uses. We used synthetic files (a 3-page and a 2-page PDF, and JPG, PNG and WebP test images), ran each tool and downloaded each result. As a cross-check, the test web server logged the size of every request body it received.

Tool and test file	Requests while processing	Result
Images to PDF JPG + PNG + WebP	2 code files from pdfnook.net (first use only)	PDF, 112 KB
PDF to images 3-page PDF	3 code files from pdfnook.net (first use only)	ZIP of 3 PNGs
Merge PDFs 3-page + 2-page PDF	2 code files from pdfnook.net (first use only)	5-page PDF
Extract PDF pages pages "3, 1"	2 code files from pdfnook.net (first use only)	2-page PDF
Compress PDF preserve text	2 code files from pdfnook.net (first use only)	12% smaller
Compress PDF smaller scanned copy	3 code files from pdfnook.net (first use only)	PDF created (larger than our tiny text-only test file, and the tool said so)

Totals across all runs, including the offline runs: 0 requests with a body, 0 POST/PUT requests, and no requests to any host other than pdfnook.net, fonts.googleapis.com and fonts.gstatic.com. Every request our test server received during the tool runs was a GET, with 0 bytes of request body. No requests went to Google Analytics or Supabase.

Last tested: 19 October 2026. If we change how files are processed, we'll update this page and its date.

07 / References

Sources

Chrome for Developers: Open Chrome DevTools; Network features reference.
Firefox Source Docs: Network Monitor; Toolbar; Request details; Throttling.
Apple: Enabling Developer Features. WebKit: Enabling Web Inspector; Network Tab.
Libraries used by Paperfoundry: pdf-lib, PDF.js.

You're welcome to link to or quote this guide. The browser steps in section 3 and the checklist in section 5 apply to any website. Read more in our privacy notice or about Paperfoundry.