How we run image codecs in your browser
Every converter on Convertur works the same way. Your file stays on your device. We don't keep that promise with a policy. It follows from how the software is built.
This post walks through each step, from the file you pick to the converted download. All of it happens inside your browser tab.
Why WebAssembly
Image codecs, like the HEVC decoder behind HEIC, are large programs written in C over many years. A rewrite in JavaScript would be slow and would bring new bugs. WebAssembly lets us compile the original C code into a format the browser runs at close to native speed.
So the same code a desktop app uses runs in the page. There is no server round trip, no upload and no queue.
Loading a codec on demand
We only fetch a codec the first time you open a tool that needs it. Each decoder sits in its own chunk. The landing page stays light, and you only download the code you use.
On later visits the browser can reuse a cached codec. Some tools also offer an optional offline engine cache. Whether it stays available depends on the browser keeping that site data.
Keeping the main thread free
Heavy conversions run in a Web Worker, so the page keeps responding while the work runs. The worker sends progress back to the interface. If you cancel a job, we shut the worker down.
Some conversions are simpler. For those, the browser's built-in canvas can do the job, and we skip loading a larger codec. Which route a file takes depends on its format and the output you asked for.
The download step
When a conversion finishes, the result sits in memory as a Blob. We give you an object URL to download it. Nothing is written to a server. If you close the tab, the browser throws it all away.
Batch downloads are put together in the browser too. While a job runs, the input files and results use device memory. That means very large batches are limited by how much memory the tab can use.
The privacy boundary
Local processing means the file you pick goes to browser APIs, a Web Worker or a WebAssembly module in the page. It is never attached to the requests that download app code, fonts or a conversion engine. Those requests carry normal network details, like your IP address. They don't carry the contents of your file.
This difference matters. A privacy policy can promise to delete an uploaded file later. A local-first tool never makes that server copy at all. Our contact form and site analytics are separate services. They never receive the files you convert or the results.
Limits of browser conversion
A browser tab has limited memory and CPU, so local does not mean unlimited. Convertur has no upload cap, yet a long video, a large archive or dozens of big photos can still run a phone out of memory. If that happens, split the batch into smaller groups.
Codec support also varies. Some tools use mature WebAssembly ports. Others rely on formats the browser can already decode. If your browser lacks something a tool needs, the tool should tell you. It should never send the file somewhere else in the background.
How to check it yourself
You don't have to trust our word. Open your browser's developer tools and go to the Network panel. Clear the log, then run a conversion. You will see requests for page code, and for an engine if the tool needs one. Then you will see a local blob download. You won't see a request that carries your file.
There is an even simpler test. Load a tool's engine and turn on the offline cache if the tool offers it. Then disconnect from the network and convert again. The steps differ a little between tools, but the conversion itself stays on your device.