UnuploadedGuide · Verification
How to check whether a converter uploads your files
You can inspect a converter's network activity and test whether it works offline. Use a file that contains no sensitive information: until you have checked the service, assume it could receive what you select. These checks have limits, which this guide explains.
For an Unuploaded tool that downloads an extra decoder or encoder, complete one conversion online before testing it offline. Loading the page alone may not cache the extra code.
Where the file is processed
A server-side converter receives your file for processing. That matters for a passport scan, medical result, signed contract or rental-application ID: the provider's access and retention practices apply to the uploaded copy.
Server-side conversion can handle jobs beyond the software or memory available in your browser. Local and server-based tools can both have a file picker, progress indicator and download link, so the interface alone does not tell you where processing happens.
The Network panel can show requests made during conversion. An offline test addresses a narrower question: can this conversion finish without a connection?
Test one: watch the Network tab
Open the converter in a desktop browser and open developer tools, usually with F12 on Windows or Linux, or Command-Option-I on a Mac. Select Network and reload once so the panel records the page loading. Clear the recorded list with the panel's Clear control, then choose your test file and start conversion.
A script or WebAssembly download before processing may be converter code arriving on your device. To investigate an upload, inspect new requests: their destination, method and any payload the browser exposes. POST or PUT requests can carry files, but the method alone is not proof. File data may be encoded, split across requests or sent another way. In Chrome, select a request and open Payload to inspect the query parameters or form data that DevTools makes available.
Select All to avoid hiding request types with a filter. Inspect WebSocket connections and their messages as well; a WebSocket can carry file data. Do not treat the Size column as a direct upload measurement: it can describe a resource received by the browser. Look at request details and payloads rather than inferring file handling from a count or size alone.
Conversion time alone cannot locate the work. A slow connection may delay a library download before local processing begins, and both device performance and a remote service's workload can affect the wait. Compare observed requests and offline behavior instead of treating a speed difference as proof of an upload.
Test two: turn the network off
Load the converter and complete a conversion online so any extra components have a chance to download. Disconnect the device from the internet, then use a different test file without reloading the page. Check that the conversion finishes and that its output contains the expected content.
A successful conversion with the device disconnected shows that this conversion can run locally. Failure alone does not show that it needs a server: the page may lack a cached component, reject the input format or encounter a browser problem.
Reloading an uncached page while offline tests whether the page can load, not where it converts files. Keep the loaded tab open for this check. Extra decoders or encoders may need a completed online conversion before they are cached, and a cache that is cleared or replaced may need warming again.
For example, prepare the decoder with an online conversion, then try the HEIC-to-JPG converter while disconnected. The result applies to the file, browser and page version you tested; it does not show how a page behaves when a connection is available.
Read the file-handling policy
Look for descriptions of where processing happens, whether files are stored and who can access them. A policy is the provider's account of its practices, not an independent test. The following phrases answer different questions.
"Files are automatically deleted after 24 hours." Read this alongside the description of where processing and storage happen. For server-processed files, it describes retention after upload; it does not mean the service never received a copy.
"Encrypted in transit" or "secure connection." TLS protects the connection to the destination. By itself, it does not prevent the receiving service from accessing a file or control what happens after it arrives.
"We do not look at your files." This describes an access policy, not where conversion happens. It neither establishes nor rules out an upload; look for a separate explanation of processing and storage.
"Processed on our secure servers." This describes server-side processing. Check the provider's storage, access and retention terms before sending a file.
Language describing local processing includes "in your browser", "client-side", "on your device" and "no server". Read any technical explanation and compare it with the network and offline checks, allowing required code to load first.
What these tests do and do not prove
These checks apply to the run you observed. A page can behave differently online, with another file type, in another browser or after an update. Repeat checks when relevant conditions change rather than treating one successful conversion as permanent assurance.
A tool that converts files locally can still load analytics or advertising that records a visit. Requests for those services are a separate issue from sending the document itself; inspect them and the provider's disclosures rather than treating local conversion as a complete privacy result.
These checks do not validate the quality of the conversion. Open the output and inspect its content, such as page order, image detail or audio, before relying on it. Keep the original file.