How to check if a PDF tool uploads your file

1. Open the Network panel first

Make a small test PDF with a distinctive filename and a sentence you can recognise. Open developer tools and start Network recording before loading or reloading the tool page. Keep recording throughout file selection, processing and downloading.

1. Chrome or Edge: open the browser menu, choose More tools, then Developer tools. Select Network. Keep the record button active and enable Preserve log so navigation does not clear the evidence.
2. Firefox: open the application menu, choose More tools, then Web Developer Tools. Select Network and enable Persist Logs in the panel settings before loading the tool.
3. Safari on Mac: in Safari Settings, open Advanced and enable features for web developers. From Develop choose Show Web Inspector, then Network. Enable Preserve Log before loading the tool.

Keep the initial request list, including WebSocket connections opened during page load. Leave the filter on All initially: uploads can use resource types beyond Fetch/XHR. Filter WS to inspect WebSocket rows and their outgoing messages during conversion and after reconnecting.

2. Look at outgoing data

Choose your sample and perform the conversion. Watch for requests appearing immediately after selection and after pressing the download button. A large POST or PUT is a reason to inspect further. Click it and review Headers, Payload or Request, depending on your browser.

A multipart/form-data request can contain a file part with a filename and binary content. Other tools send raw PDF bytes, an application/octet-stream body, base64 text inside JSON, or several smaller chunks. Search for your sample’s filename or distinctive text where the panel exposes readable content. Compression and encryption can hide those clues.

Check the outgoing payload size where available. The Size or Transferred column often describes the response coming back, not the upload going out. A tiny response can acknowledge a large upload. Request method alone is also insufficient: a POST might carry a short usage event, while document text could be sent in a URL.

3. Repeat the task offline

First complete one harmless conversion online so the tool can load its scripts, workers and fonts. In Chrome or Edge, choose Offline from the Network throttling menu. In Firefox or Safari, disconnect the computer’s network connection if an offline control is unavailable. Keep the already loaded page open.

Select the sample again and repeat the task. A working download suggests the processing can happen locally. Reloading the page tests something else: whether the website itself is available from cache. A failed offline conversion may simply mean a required library was not loaded, so inspect failed requests before drawing conclusions.

4. Reconnect and check again

Offline success is useful evidence, not a guarantee. A page can queue data and send it when connectivity returns. Reconnect with Network recording active, wait, and check requests after another action or navigation. Background workers can also continue work beyond the visible conversion.

Separate application downloads from outgoing file data. A worker script, font or library response is normally code arriving on your device. Analytics may send only event names and counts, but the label “analytics” proves nothing: inspect the actual payload for filenames, text and encoded content. Do not share a saved network log casually; it can include private session information.

Try a local conversion

Use PDF to JPG to export pages or JPG to PDF to combine images, then run these checks yourself. Both process files in your browser. For page extraction, follow How to split a PDF without uploading it. Repeat checks when a tool changes; one observation describes that session, not every future version.