How does browser file conversion work without uploading files? A WebAssembly module loads into your browser, reads the file from local memory, runs the conversion using compiled C++ or Rust code at near-native speed, and writes the output back to memory. The file never touches a network connection. The entire pipeline runs inside a sandboxed environment on your own device.
A few years ago, "convert this file in your browser" was a polite lie.
What it really meant was: send the file to a server, wait for the server to run ImageMagick or FFmpeg, and receive the result. The browser was just a window into someone else's infrastructure. Your file left your device the moment you clicked Convert.
That architecture was not dishonest by design. It was the only realistic option. JavaScript is not fast enough to decode HEIC frames or render PDF pages at a speed that feels instant. The browser had no way to run the compiled C libraries that professional tools depend on.
WebAssembly changed this. Not gradually. It changed it completely.
What WebAssembly Actually Is
WebAssembly (Wasm) is a binary instruction format that browsers can execute directly. It is not JavaScript and does not replace JavaScript. It is a compilation target, the same way machine code is the compilation target for C++.
The workflow looks like this: you write code in C, C++, or Rust. A toolchain called Emscripten (for C/C++) or wasm-pack (for Rust) compiles that code into a .wasm binary. The browser downloads that binary, compiles it again to native machine code for your specific CPU, and runs it inside a sandboxed environment.
The result executes at roughly 80 to 90 percent of native speed. For reference, the same operations written in JavaScript typically run 5 to 30 times slower than their C counterparts. That gap is exactly why server-side conversion existed in the first place: the browser simply could not keep up.
WebAssembly shipped in all four major browsers in 2017: Chrome 57, Firefox 52, Safari 11, and Edge 16. As of 2025, it runs in 96 percent of global browser sessions. There is no meaningful compatibility question anymore.
Why This Enables Real Client-Side File Conversion
The libraries that handle serious file formats were written in C and C++ over decades. libheif, which decodes Apple's HEIC format, is C++. pdf.js renders PDFs using a JavaScript port, but the underlying codec work traces back to compiled native libraries. FFmpeg, the standard for video and audio processing, is C. ImageMagick is C.
None of these were ever going to be rewritten in JavaScript. The performance gap is too wide and the codebases too large. The only path to running them in a browser was to compile them to WebAssembly.
That is exactly what happened.
libheif.js: The HEIC decoder compiled to WebAssembly. privateconvert.io uses this to decode HEIF frames in the browser, extract raw pixel data, and re-encode as JPEG or PNG. No server involved.
ffmpeg.wasm: The complete FFmpeg multimedia toolkit, compiled to a ~22 MB WebAssembly module. Supports H.264, H.265, MP3, Opus, and hundreds of other formats entirely in the browser.
pdf.js: Mozilla's PDF renderer, used to rasterize PDF pages to canvas at 2x scale for pixel-accurate output.
canvg: An SVG parser and renderer that handles SVG files the browser's native image pipeline sometimes struggles with.
Each of these follows the same pattern: load the Wasm module into browser memory, pass the file as a byte array, run the conversion, read the output back, hand it to the user as a download. No network request. No server. No account.
The Privacy Architecture This Creates
Understanding how WebAssembly works also explains why client-side conversion is a fundamentally different privacy model, not just a marketing claim.
In a server-side converter, your file leaves your device the moment you click Convert. It crosses the internet, lands on a server you do not control, gets processed, and gets stored for some period afterward. EXIF metadata travels with image files. GPS coordinates, timestamps, device model: all of it goes to the server. Free converter services pay their infrastructure costs somehow. Uploaded file data and behavioral analytics are common answers to that question.
In a WebAssembly-based converter, the file is read by the browser's File API into local memory. The Wasm module processes it there. The output is written back to local memory and handed to the browser's download mechanism as a Blob URL. At no point does the file enter a network request.
You can verify this yourself on any WebAssembly-based converter. Open DevTools in your browser, go to the Network tab, and watch what happens when you upload a file and click Convert. On a properly built client-side tool, no outbound request containing your file appears. The conversion happens, the download triggers, and the network tab stays quiet.
This is not a privacy policy. It is an architecture constraint. A tool built this way cannot upload your files even if it wanted to, because there is no code path that does so.
How the Conversion Pipeline Works Step by Step
Here is what happens inside a WebAssembly file converter from the moment you select a file to the moment you download the result:
- File selection: The browser's File API reads the file into an ArrayBuffer in local memory. The file path on your disk is never exposed to the web page.
- Format detection: The application checks the file's magic bytes (the first few bytes of the binary) to confirm the format, independent of the file extension.
- Wasm module load: The relevant library (libheif for HEIC, pdf.js for PDFs, canvg for SVG) is loaded or retrieved from the browser's module cache if already loaded in a previous conversion.
- Conversion: The Wasm module processes the byte array entirely in memory. For standard image formats, this may happen inside a Web Worker on an OffscreenCanvas to avoid blocking the main thread.
- Output: The result is written to a Blob URL. The browser's download mechanism is triggered. The temporary Blob is revoked from memory after download.
The network tab sees none of this. The file does not leave the browser's sandboxed memory at any step.
What WebAssembly Cannot Do Well (Yet)
WebAssembly enables client-side conversion for most common formats. It does not make every conversion fast or practical.
Video transcoding is slow. FFmpeg.wasm can transcode video in the browser, but a simple MP4 to MOV conversion that takes 30 seconds natively can take 5 to 10 minutes in the browser. WASM runs at 80 to 90 percent of native speed for CPU-bound work, but video encoding is extremely CPU-bound and the absolute numbers still hurt at scale.
Memory limits on mobile are real. On iOS Safari and Chrome for Android, WebAssembly modules are constrained to roughly 300 MB of usable memory. Large files or multi-image HEIC sequences can hit this ceiling. This is why tools like privateconvert.io cap HEIC batch sizes.
Initial load time costs something. A WebAssembly binary like ffmpeg.wasm weighs 22 MB. The first load requires a download, a compilation step, and a startup sequence. Subsequent loads benefit from browser caching, but first-time users wait. Lazy loading, where the Wasm module only downloads when a user selects a file that needs it, reduces this.
For image conversion (PNG, JPG, WebP, HEIC, SVG, PDF to image), WebAssembly is fast enough that the limits are invisible in practice. For video, the honest answer is that server-side still wins on speed if that matters to you.
Why This Matters Beyond Privacy
The privacy angle is real and it matters. But WebAssembly-based file conversion also solves practical problems that have nothing to do with data sensitivity.
It works offline. Once the page and its Wasm modules are cached by the browser, you can convert files with no internet connection. This is why progressive web app installs make sense for tools like this: the converter is available the same way a desktop application is, regardless of network status.
It scales to zero infrastructure cost. A server-side converter that handles 100,000 conversions per month needs real compute capacity. A WebAssembly converter offloads all of that to the user's device. The server delivers static files. The browser does the work.
It eliminates file size limits imposed by server constraints. Upload-based tools cap file sizes to control server load and egress costs. A client-side tool's practical limit is the user's available memory, which on a modern laptop is substantially larger than the 10 MB or 25 MB caps common on free server-side tools.
Try It Without Taking My Word for It
privateconvert.io is built on this architecture. 28 converters, including HEIC to JPG, PDF to PNG, SVG to WebP, and WebP to PDF, all running in the browser using the WebAssembly libraries described above.
Open the Network tab in DevTools before you select a file. Watch it during the conversion. The absence of an outbound file request is the proof that the privacy claim is structural, not decorative.
WebAssembly made this possible. It did not make it easy to build, but it made it possible to do correctly.
Frequently Asked Questions
What is WebAssembly in simple terms?
WebAssembly is a way to run compiled code written in C++, Rust, or other languages directly inside a web browser at close to native speed. Browsers can execute it safely without giving it access to your system. It is what allows browser-based tools to do things JavaScript cannot handle fast enough on its own.
Is WebAssembly safe to run in a browser?
Yes. WebAssembly runs inside the same sandbox as JavaScript. It cannot access your filesystem, network, or hardware without explicit browser APIs. A Wasm module can only touch memory the browser has explicitly allocated to it. It cannot read your disk or make network requests on its own.
Why do some browser file converters still upload files if WebAssembly exists?
Because building a WebAssembly-based pipeline is harder than building a server-side one. A server-side converter needs a web form and a call to FFmpeg. A client-side one requires porting the relevant library to Wasm, handling memory constraints on mobile, managing worker threads to avoid blocking the UI, and dealing with edge cases in browser compatibility. The server approach is faster to ship. Some tools also prefer to have access to the files, for analytics or future product reasons.
Which file formats can be converted in the browser using WebAssembly?
Images (PNG, JPG, WebP, HEIC, SVG), PDFs to image formats, and HTML to PDF are all practical with current Wasm libraries. Audio conversion is feasible with ffmpeg.wasm but slow. Video transcoding works but is significantly slower than native or server-side alternatives. Document formats (DOCX, XLSX) remain difficult because LibreOffice's Wasm port is experimental and impractical for production use.
Does browser-based conversion work on iPhone?
Yes, for image formats. Safari on iOS supports WebAssembly and the necessary canvas APIs. HEIC decoding via libheif.js works in Safari on iPhone. The memory limits on iOS are tighter than desktop, so very large files or large batches may fail. For standard single-file conversions, it works reliably.
Written by privateconvert.io
Top comments (0)