Privvert Blog

You drag a PDF into a converter, wait five seconds, download the result, and move on. That routine raises a practical question: can online tools see my files? In many cases, yes. If a site uploads your file to its server for processing, the operator can technically access the contents, store a copy, log metadata, and inspect the output. The risk exists because the architecture requires it.

This is the part many "free" utility sites obscure. They market convenience, not data flow. But file handling is not mysterious. If your browser sends the file over the network, another computer receives it. At that point, privacy depends entirely on their retention practices, internal access controls, and honesty.

When online tools can see your files

The simplest rule is this: if a tool requires an upload, the service can see the file in transit and on its server. Encryption in transit, usually TLS, protects against third parties snooping on the connection. It does not stop the service itself from reading the file after it arrives.

This risk extends beyond the obvious text on a page. An image may contain EXIF metadata, which can include GPS coordinates and device identifiers. A PDF can include author names, revision traces, or hidden text layers that survived a visual redaction. Use a tool to view and strip PDF metadata locally if you want to see what is actually hidden in your documents.

Sometimes the file contents are not even the primary target. A site may log your IP address, browser details, file names, and processing history. A file titled "Termination-Lists-Q4.pdf" tells a story even if the operator never opens the document.

The "We Delete Your Files" promise

Deletion policies reduce the window of exposure, but they do not eliminate it. If a service says files are deleted after 60 minutes, those files still exist on their systems for an hour. During that window, they are vulnerable to cached storage, failed jobs that linger in queues, and unauthorized access by employees or attackers.

There is also a functional difference between application-level deletion and infrastructure-level wiping. Data can linger in backups or vendor object storage long after the website dashboard says it is gone. As a reader, you cannot verify the full chain of destruction.

The local processing model

A browser-based tool is not automatically private. Many sites look like they are working locally while quietly uploading files in the background. What matters is where the computation occurs. When processing happens in the browser, your files never leave your device. The site serves the code, and your browser runs it locally using WebAssembly or native web APIs.

This is the model Privvert uses for every task possible. For example, you can redact a PDF in the browser without an upload, or strip GPS data from photos on your own hardware. This architecture removes the need to trust a service's deletion policy because they never received the data in the first place.

What a site operator learns from one file

People tend to worry about high-stakes leaks like tax returns, but routine files are equally revealing. A JPEG can expose a home address, and a design asset can reveal a client identity in the color profile. If you are sending sensitive business documents, you should add a PDF password locally before even considering a cloud-based share.

Even failed uploads provide telemetry. Browser fingerprinting and request metadata tell a service what operating systems you use and what file types dominate your workflow. This is why the upload-driven model is structurally hostile to privacy; it demands you hand over raw material first and trust invisible promises later.

How to verify a tool's behavior

You can verify whether a tool uploads your data using the network tab in your browser's DevTools. Load the page, open the network monitor, and select a file. If you see a POST or PUT request with a substantial payload, your file is being uploaded. If a site claims it does not upload but your 50MB video triggers a 50MB network request, the claim is false.

A simpler test is to disable your internet connection after the page loads. If you can still convert image formats locally while offline, the tool is operating on your device. Local tools are verifiable; upload-based tools are not.

Choosing when to trust the cloud

Context determines risk. Converting a public image for a blog is different from processing a medical record or an unreleased product mockup. If disclosure would be legally or professionally damaging, do not upload it to a server. This includes drafts, which often contain more hidden metadata and revision history than the final versions.

Before using any file tool, ask where the processing happens. If the answer involves an upload "to the cloud," treat it as a deliberate risk rather than a technical necessity. Privacy is about reducing unnecessary exposure by keeping your data on the only machine you actually control: your own.