Are online file converters safe? How to check whether a tool uploads your files

“Online” describes the page, not where the file is processed

Two converters can look identical while having opposite privacy architectures.

A server-side converter sends the file over the internet, processes it on remote infrastructure, then returns a result. HTTPS encrypts the journey, which is essential, but the service still receives the readable file at the endpoint. Safety depends on retention, access controls, logging, backups, subprocessors, jurisdiction, incident response, and whether the public policy matches the deployed system.

A local browser converter downloads application code, then gives the selected file to JavaScript, Web Workers, WebAssembly, Canvas, or browser file APIs on the device. The page is online, but the file transformation does not require an upload. This removes entire categories of server storage and breach risk.

“Client-side” is not a magic word. You still trust the delivered code, the website origin, your browser, installed extensions, and the device. The useful question is narrower and testable: did this workflow transmit my file or its contents?

The five-minute Network-panel test

Chrome’s official documentation says the Network panel records requests while DevTools is open. Use it to observe a converter rather than guessing from its marketing.

1. Create a harmless sample file. Do not begin a privacy test with a passport, tax return, medical record, or client database.
2. Open the converter page, then open developer tools with F12 or Ctrl+Shift+I on Windows/Linux, or Command+Option+I on macOS.
3. Select the Network panel. Confirm the record button is active.
4. Let the page finish loading, then select Clear. This removes ordinary page assets from the visible log so the processing step is easier to isolate.
5. Choose the sample file and run the conversion.
6. Inspect every new request. Pay particular attention to POST, PUT, fetch, XHR, GraphQL, WebSocket, and requests with a transfer size similar to the sample.
7. Click a suspicious request and inspect Headers, Payload, Initiator, and Timing. Do not publish or export a HAR containing private headers, cookies, or file content.

The Chrome Network reference documents the Method, Domain, Size, Initiator, Payload, and other columns used for this inspection.

Distinguish an upload from a code download

Choosing a file can legitimately trigger a network request without uploading that file. A performance-conscious tool may wait until user intent before downloading a large PDF engine, image model, WebAssembly module, or worker script. In that case the response size can be large, but data travels from the site to the browser.

An upload usually has a request body. Look for a payload, multipart form data, a blob, a binary request, or a transfer whose size tracks the selected input. The filename may be absent or changed, so searching only for the filename is not enough.

FileGizmo lazy-loads heavy processing assets only when they are needed. Those assets come from the FileGizmo origin. The selected file is passed from the page to a dedicated browser worker, which is an in-device message rather than an internet request. Try the test with Merge PDF or Compress image and watch the direction and payload of each request.

What the test proves and what it cannot

An observed zero-upload run is strong evidence about that run. It is not a mathematical proof about every future deployment, every input type, or hidden behavior outside your observation window.

Improve the test:

• Keep DevTools open before choosing the file; requests made earlier are not retroactively logged.
• Test the actual action, including preview, conversion, download, and any “AI enhance” option.
• Repeat with a file large enough that an upload would be obvious, but still harmless.
• Filter for third-party requests and inspect which companies receive analytics or error data.
• Disable cache for a clean run if you understand the performance impact.
• Test offline after the required assets have loaded. A local workflow may continue; a server converter will not.
• Repeat after a meaningful product update because deployed code can change.

A service worker can serve requests from cache, and browser extensions can make their own requests. The Network panel’s Initiator and Domain columns help separate these from the converter.

A repeatable test record, not a trust badge

On 18 July 2026, FileGizmo’s release QA opened the production build, selected harmless fixtures, and completed real conversions across PDF, image, CSV, text, and developer workflows. The gate rejects unexpected eager heavyweight requests, verifies that processing workers stay isolated by tool, and exercises the site with JavaScript disabled where progressive enhancement applies. The browser run also checks mobile width, keyboard focus, error announcements, and downloadable outputs.

That record is deliberately scoped. It supports the tested build and fixtures; it is not a permanent certificate for future code. Each release reruns the same gate, while users can repeat the Network-panel test against the deployed site. A meaningful privacy claim should survive both automated regression testing and an ordinary person clearing the log and watching one conversion.

When documenting another service, record the date, browser, route, input type and approximate bytes, action taken, request method, destination domain, outgoing payload size, and result. Avoid a vague “safe/unsafe” score. A dated observation such as “one multipart POST approximately matched the sample size” is more useful and reproducible than a badge.

Read the privacy policy like an engineer

Policies matter, but look for operational answers rather than adjectives such as “secure” or “military-grade.” Useful questions include:

• Is processing local, regional, or global?
• Is the file stored, and for exactly how long?
• Are backups included in the deletion window?
• Is content used for model training, product improvement, abuse detection, or human review?
• Which subprocessors receive the file or extracted data?
• Is an account required, linking documents to an identity?
• Can the operator technically access the file even if policy says staff normally do not?

“Files deleted after one hour” is better than silence, but it still describes an uploaded file. “Files never leave the device” is a stronger architecture only when the Network test agrees.

Match the tool to the sensitivity

For public or disposable files, convenience may dominate. For employment records, legal evidence, unreleased financials, health information, identity documents, private photographs, or customer exports, prefer local software or a browser tool you have verified.

Also consider output correctness. A private converter that damages a PDF, strips required color profiles, changes spreadsheet identifiers, or exposes hidden text is not safe for the task. Privacy, integrity, and availability all matter.

FileGizmo’s claim, stated precisely

FileGizmo serves static pages and self-hosted processing code. Tool workflows read selected files in the browser and do not send those file bytes to a FileGizmo processing server. There is no account or remote file queue. Some tools download a dedicated worker, codec, or model from the same origin after you show intent; that is why “the Network tab is empty” should be understood as zero file-processing requests, not “a modern webpage never downloads code.”

FileGizmo also publishes its browser-enforced security policy. On ordinary tools, the connect-src 'self' rule prevents page code from connecting to third-party origins. The address-geocoding route is the single documented exception because it must send individual addresses to Geoapify; that permission is scoped only to that route.

You do not need to accept that claim on trust. Open the Network panel, clear it, use a harmless sample, and inspect what happens. A privacy promise is more valuable when the product teaches users how to challenge it.