Search "convert PNG to JPG" and you'll get a wall of free converters — most ad-supported, most operating on the same business model: upload your file, run a server-side conversion, return the result. The flow is so smooth most people never think about what happens between upload and download. This post walks through what actually happens, what the privacy policies say (and don't say), and how to tell when a converter never sees your file at all.

What "upload to a server" actually means

When you click upload on a typical converter, the browser POSTs your file to the provider's server. The file lands in a temporary directory, the conversion runs, and a link to the result is returned. Three things happen during that flow that the UI doesn't surface:

Your file persists for at least the conversion's duration. Often longer, to support retries or downloads.
It can be logged. Server access logs, error logs, CDN logs, and analytics all routinely capture file names, IPs, and metadata.
It crosses jurisdictions. The provider may run in a country whose data protection rules differ from yours. EU users uploading to US servers cross that boundary on every conversion.

What privacy policies typically say

Read enough of these and a pattern emerges:

"Files are deleted after 24 hours" — common, but no way to verify, and 24 hours is enough time for backup snapshots to capture them.
"We do not share your files with third parties" — usually qualified by "except with our service providers", which can mean almost anyone.
"By using this service you grant us a license to process your content" — broad enough to cover model training in some interpretations.
Silence on logs and analytics — privacy policies rarely enumerate which logs collect what.

None of these are necessarily abusive. They reflect normal operational reality for a server that handles user uploads. They are also the reason the most privacy-respecting answer is "don't send the file at all."

The 2026 alternative: browser-only conversion

Modern browsers can run image and video codecs natively — the same codecs that ship in ffmpeg, libwebp, and libheif — via WebAssembly. The conversion happens entirely in the tab. The file never leaves the device.

This isn't a limited subset. Every conversion this site supports — PNG, JPG, WebP, AVIF, HEIC, GIF, MP4, WebM — runs in the browser. The pipeline:

You drop a file into the dropzone. The file goes into the page's memory as a File object.
A WebAssembly module — typically libwebp, libheif, or ffmpeg.wasm — decodes the source format.
The decoded pixel data is encoded into the target format, again entirely in the tab.
The result is wrapped in a Blob and offered as a download.

The browser's network panel will show zero outbound POST during the conversion. The only network activity is the initial page load and any analytics or ad scripts the site happens to ship. (Picovert ships analytics, but not for the file contents — we couldn't read them even if we wanted to, because they never reach our server.)

How to tell which converters are browser-only

Five practical checks, in increasing rigor:

Look for the claim. Browser-only converters tend to lead with it because it's a meaningful differentiator. If the homepage doesn't say anything about where conversion happens, assume server.
Open DevTools and convert a file. Watch the Network tab. If no POST/PUT request fires while the conversion runs, the file isn't uploaded. This is the single most reliable check.
Disconnect from the network mid-conversion. If the conversion still completes, it's running locally.
Check whether the page uses Service Worker or WASM. View source and search for .wasm. Browser-side conversion almost always loads a WASM module.
Look for the source code. Open-source converters expose what they do. Picovert's repository is public.

When server-side is fine

Server-side conversion isn't inherently bad. There are real use cases where it's the right architecture:

Files that don't fit in browser memory — a 10GB raw video can't sensibly run through ffmpeg.wasm.
Conversions that need centralized GPU resources — AI upscaling, super-resolution, complex video transcoding pipelines.
Workflows where the output should be stored in a shared location — team-shared assets, content pipelines.

For a one-off conversion of personal photos, none of these apply. Server-side is just engineering inertia from before WebAssembly was viable.

What we do at Picovert

We made a deliberate choice early on: every tool runs in the browser. We don't run a conversion server. There is no S3 bucket holding your photos. There is no database with a table of "user uploads". This isn't a marketing line — it's the only architecture we ship, and you can verify it with the DevTools check above.

The trade-off is that we can't accept files larger than a browser tab can hold (roughly 2 GB on most machines), and we can't do conversions that require multi-GPU server clusters. For the 99% case — converting your phone photos, optimizing assets for a website, turning a GIF into an MP4 — the browser is enough.

Bottom line

"Online converter" should not automatically mean "uploads your file". In 2026, browser- based conversion is mature, fast, and free. If a converter doesn't tell you where your file goes, assume the answer is "to a server you don't control." The DevTools test above takes 30 seconds and tells you the truth.