Record network activity from file selection through download, inspect request destinations and payloads, and repeat the conversion offline. Use both tests because either signal alone can be misleading.
PNG → WebP
Separate browser-based from local-only processing
Web applications can use the File API and FileReader to access files that a user deliberately selects. That makes client-side conversion possible, but it does not guarantee that the selected bytes stay on the device. Once a script has read a file, it may process the bytes locally, send some or all of them in a request, or combine both approaches. Product wording and observed behavior should therefore be evaluated separately.
Read the privacy notice and tool documentation for statements about local processing, uploads, retention, analytics, and third-party services. If the description is missing or cannot be verified, do not test with a confidential original. Create a disposable image that contains no names, faces, locations, or valuable content. Match the format and approximate size of the real material so that the test exercises a similar path without exposing actual information.
Check which permissions the page requests. An image converter normally needs only the files you choose, not broad folder, clipboard, camera, or microphone access. If a permission appears unrelated to the task, stop and investigate before continuing. Record the browser version, site address, date, and permission state so that the result can be reproduced later.
- Read processing and retention claims
- Use a disposable non-sensitive sample
- Review requested browser permissions
Browser-based describes where code runs; it is not proof that no file data is transmitted.
Prepare a clean network recording
Open the browser's Network panel, make sure recording is active, and clear existing entries. First observe the page with no file selected so you can identify ordinary requests for scripts, fonts, analytics, advertisements, or update checks. Enable log preservation if navigation or a download would otherwise erase entries. A baseline makes it easier to isolate requests caused by selecting and converting the image.
Clear the log again immediately before choosing the sample. Select the file, run the conversion, wait for completion, and download the result without performing unrelated actions. Review the time, URL, domain, method, status, resource type, and transferred size of new requests. Pay particular attention to POST and PUT requests, multipart form data, binary request bodies, and transfers that appear close to the sample's size.
- Capture a no-file baseline
- Clear the log before file selection
- Preserve entries through the download
Interpret requests instead of counting them
A network entry does not automatically mean that the image was uploaded. Analytics pings, error reports, fonts, and application assets may appear during a completely local conversion. Conversely, a small transfer is not automatic proof of safety. Image data could be compressed, split into chunks, transformed, or reduced to selected information before transmission. The useful question is what data went where and when.
Inspect the destination domain, content type, request headers, payload view, and timing relative to file selection. Give the sample a unique but non-sensitive filename and check whether that name appears in a request body or query string. If the browser hides a body, encryption prevents inspection, or a service worker changes the path, document that limit rather than declaring the tool safe. Absence of visible evidence is not the same as evidence that no transfer occurred.
- Distinguish analytics from file traffic
- Inspect domains, methods, and payloads
- Record what could not be observed
The presence or absence of requests matters less than the data, destination, and timing of each request.
Cross-check with an offline conversion
After the page and its required code have loaded, switch the browser's network emulation to offline and repeat the test with the same sample. If conversion and download still finish, that supports a client-side processing explanation. If conversion fails, the tool may depend on a server, but an uncached script, a license check, or another missing resource could also be responsible. Treat the result as evidence, not a complete verdict.
Successful offline operation does not rule out delayed transmission after connectivity returns. Watch the network log when going online again, and repeat the test in a clean browser profile or private window to control caching and service-worker state. Note whether the tool behaved differently on the first and second run. Combining the online log with an offline test is much stronger than relying on either one in isolation.
- Load required code before going offline
- Watch for requests after reconnecting
- Control cache and service-worker state
Verify the output and make the process repeatable
Even if no file upload is observed, the converted image may still expose private information. Reopen the download and inspect visible names, faces, notifications, addresses, and location clues. Use a metadata inspector to review location, capture time, device, author, and description fields. Format conversion and metadata removal are different operations, so clean a dedicated sharing copy when necessary and inspect it again.
Document the site and browser version, test date, sample format and size, observed domains, payload limits, offline result, and policy wording. Repeat the test after significant site or browser changes. For highly sensitive material, prefer a verifiable offline desktop workflow on a controlled device instead of depending on a public page whose implementation can change.
In an organization, maintain an expected-domain list and pause processing when a new destination or permission appears. Run the test in a controlled profile without unrelated extensions, because extensions can alter traffic and file access. Store observations rather than the sample bytes in the audit record. Preserve the private original separately and move only the verified delivery copy into the approved sharing location.
- Inspect visible content and metadata
- Record versions and observed domains
- Retest after implementation changes
Upload verification is only one privacy check; the exact delivery file must also be reviewed.
Key takeaways
- The File API lets a page read a selected file locally, but page code can still send the resulting data over the network.
- Clear and preserve the network log immediately before selecting a non-sensitive test image.
- Inspect request timing, method, destination, payload, and size instead of treating every request as an upload.
- Use an offline test as supporting evidence, then review the downloaded file for visible and hidden private information.
Frequently asked questions
Does FileReader keep a file off the network?
FileReader can read a selected file in the browser, but it does not prevent page code from sending the resulting data in a later request.
Does any Network panel request prove an upload?
No. It may be analytics or an application resource. Inspect its destination, method, payload, size, and timing.
Is an offline conversion proof of complete privacy?
No. It supports local processing, but it cannot exclude delayed transmission or other online-only behavior after reconnection.
What file should I use for the test?
Use a disposable image with no sensitive content, but keep its format and approximate size similar to the files you expect to process.
Can I trust the result forever after one test?
No. Site code, policies, dependencies, and browsers change, so repeat the test before sensitive work and after significant updates.