How File Conversion Works Without Uploading Anything

The way conversion sites normally work

The conventional online converter is a website with a server behind it. You choose a file, your browser uploads it, the server runs conversion software, and you download the result. It works, and for two decades it was the only option available on the web.

It also means handing your file to someone else. Whatever the privacy policy says, the file leaves your device, travels across the network, and sits on a machine you have no visibility into for some period of time. For a screenshot of a menu that is unremarkable. For photographs with GPS coordinates in the metadata, scans of documents, medical images, unreleased work, or a video of your family, it is a meaningful decision that most people make without noticing they are making it.

The upload model has practical costs too. Large videos take as long to upload as they do to convert. Free tiers cap file sizes because bandwidth and CPU cost the operator real money. Queues appear at busy times. None of these are anyone behaving badly — they are the unavoidable economics of doing the work on someone else’s computer.

WebAssembly: real software, running in a tab

The thing that changed is WebAssembly, a compilation target that browsers execute at close to native speed. It means software written in C or C++ — including software that predates the web as a serious platform — can be compiled and run inside a browser tab without modification to its logic.

That matters here because image conversion is a solved problem with mature solutions. ImageMagick has been the standard tool for the job since 1990, handling hundreds of formats with decades of accumulated edge-case handling. Convertmaxxing runs ImageMagick compiled to WebAssembly: the same battle-tested engine that runs on servers, executing on your machine instead. The engine downloads once, is cached by your browser, and converts everything from JPEG and PNG to HEIC, camera RAW, AVIF, and JPEG XL.

Video takes a different path. Rather than shipping a video engine, the browser already has one — WebCodecs exposes the hardware-accelerated encoders and decoders your device uses for video calls and streaming. Conversion here drives that pipeline directly, which is why video conversion can be genuinely fast: it is the same silicon your phone uses to record in the first place.

What "never uploaded" actually means, and how to check

When conversion runs in your browser, there is no upload step to secure, because there is no upload. The file is read from disk by the page, processed in memory, and written back out as a download. There is no server holding it, nothing to retain, nothing to leak in a future breach, and no policy you have to trust.

This is a claim you can verify rather than take on faith, which is unusual for privacy promises. Open your browser’s developer tools, switch to the Network tab, and run a conversion. You will see the page load, you will see the conversion engine download the first time you use it, and you will see no request carrying your file anywhere. Leave the tab open and watch for as long as you like.

One honest clarification about what this does not mean. Running in the browser is not the same as running offline — the page and the conversion engine still have to load from the network the first time. What it means is that your files specifically never travel, which is a narrower and more verifiable claim than "we are private".

The limits this approach imposes

Browser-based conversion has real constraints, and a tool that hides them is not being straight with you.

Your device does the work, so its speed determines conversion speed. A large batch of AVIF encodes on a phone will take a while, because AVIF encoding is genuinely expensive and a phone has less to give than a desktop. There is no queue and no size tier, but there is also no server farm quietly absorbing the cost.

Memory is bounded. WebAssembly heaps cap out around 4 GB and do not shrink once grown, which is why image jobs here run strictly sequentially in a disposable worker that recycles itself rather than accumulating memory across a long batch. Very large images can still exhaust it, and the honest response is an error rather than a silent failure.

Video encoding support varies by browser. Because conversion uses the browser’s own pipeline, what your browser can encode determines what is available — a combination that works in Chrome may be unavailable in Firefox on the same machine. Convertmaxxing probes WebCodecs at conversion time and reports what it finds, rather than producing a file that does not play. MP3 and WAV are the exceptions that always work, because those encoders ship with the site.

Some formats are impossible rather than unfinished. HEIC cannot be created here because no HEIC encoder is available to the engine, for patent reasons — the same reason browsers do not display HEIC natively. Camera RAW formats are read-only because RAW files can only meaningfully come from a sensor. Where a limit exists, the honest thing is to name it.

When a server-side converter is still the right tool

Browser conversion is not universally better, and it is worth being clear about where it loses.

Very large video files — hours of high-resolution footage — are genuinely better served by dedicated desktop software like HandBrake or FFmpeg, which have no browser memory ceiling and expose far more control over encoding parameters. Automated or scheduled conversion belongs in a script on a server, not in a tab someone has to keep open. Formats requiring specialist support, such as PDF processing or animated GIF work, need tools built for them.

What browser conversion is genuinely best at is the common case: you have some files, you need them in a different format, and you would rather not upload them to a stranger or install anything. No account, no queue, no size tier, no file leaving your device — and for that case, the technology has quietly become good enough that the old trade-off no longer applies.