The Fat Client Returns: How WebAssembly Is Killing the Upload-to-Convert Model

WASI 0.3, WebGPU, and mature Wasm libraries are making server-side file conversion obsolete. Learn how browser-based tools like Fileza.io process files locally using ffmpeg.wasm, pdf-lib, and more.

Published April 19, 2026 · Updated April 19, 2026

For the last fifteen years, the dominant model for file conversion on the web has been simple: upload your file to a server, wait for the server to process it, download the result. CloudConvert, Zamzar, OnlineConvert, and dozens of similar services all work this way. You hand your file to someone else's computer, that computer does the work, and you get the output back.

This model made sense when browsers were thin clients with limited computational capabilities. JavaScript was slow. Local storage was constrained. The idea of running FFmpeg or a PDF processing library inside a browser tab would have been absurd in 2010. So the work went to the server, and users accepted the trade-offs: upload wait times, file size limits, privacy concerns about sending personal documents to unknown servers, and the per-conversion costs that fund these services through subscriptions or advertising.

That era is ending. WebAssembly has matured to the point where computationally intensive file processing — video transcoding, image format conversion, PDF manipulation, audio encoding — runs at near-native speed inside the browser. The fat client is back, and it is killing the upload-to-convert model.

Why Now: The Technical Inflection Point

WebAssembly (Wasm) has been available in browsers since 2017, but for years it was primarily used for porting games and niche applications. The ecosystem was immature. Tooling was rough. Performance was good but not great. Several developments in 2025 and 2026 have pushed Wasm past the tipping point for file processing workloads.

WASI 0.3 and Async Support

The WebAssembly System Interface (WASI) defines how Wasm modules interact with the outside world — reading files, accessing the network, managing memory. WASI 0.3, which reached a stable preview in February 2026, introduced asynchronous I/O support through its component model. This matters enormously for file processing because many conversion operations involve waiting for data: reading large files from disk, streaming video frames, or performing multi-pass encoding where each pass depends on analysis from the previous one.

Before async WASI, Wasm modules either had to process everything synchronously (blocking the browser's main thread and freezing the UI) or rely on complex workarounds using Web Workers and shared memory. WASI 0.3 makes async operations a first-class concept, which means Wasm-based conversion tools can process large files without hanging the browser, provide progress feedback during long operations, and handle streaming workloads cleanly.

WebGPU for Compute

WebGPU, which reached broad browser support in 2025, gives WebAssembly modules access to GPU compute shaders. For file conversion, this unlocks hardware-accelerated image processing, video decoding and encoding, and AI-based enhancement operations like upscaling and noise reduction.

The practical impact is that operations which previously required server-side GPUs — real-time video transcoding, batch image processing with ML models, complex PDF rendering — can now run on the user's own GPU through the browser. A modern laptop with a discrete or integrated GPU can transcode video at speeds that would have required a dedicated server a few years ago.

Mature Wasm Libraries

The third and arguably most important factor is library maturity. The tools needed to process files in the browser are no longer experimental — they are production-grade.

ffmpeg.wasm compiles the full FFmpeg multimedia framework to WebAssembly. It supports hundreds of codecs, container formats, and processing operations. Video conversion, audio extraction, format remuxing, stream copying, filter application — the same capabilities that FFmpeg provides on the command line are available in the browser. Performance is roughly 2-5x slower than native FFmpeg for CPU-bound operations, which is fast enough for most practical workloads, especially when the alternative is uploading and downloading the file.

pdf-lib provides PDF creation and modification in JavaScript, with Wasm acceleration for computationally intensive operations. It can merge PDFs, split pages, add text and images, fill forms, and manipulate document structure — all client-side.

heic2any converts HEIC/HEIF images (the default format on iPhones) to JPEG, PNG, or other formats using a Wasm-compiled HEIF decoder. This solves one of the most common conversion needs for mobile users without requiring a server round-trip.

libvips and sharp (via Wasm builds) provide high-performance image resizing, format conversion, and metadata handling. The Canvas API handles simpler image conversions, but for operations that require precise color management, ICC profile handling, or specific encoder configurations, these libraries fill the gap.

pdfjs-dist (Mozilla's PDF.js) renders PDF pages to canvas with high fidelity, enabling PDF-to-image conversion and PDF preview entirely in the browser.

The Architecture of a Client-Side Converter

Understanding how a browser-based converter actually works clarifies why this approach has become viable. Fileza.io serves as a concrete example because it processes over 30 file formats entirely client-side using the technologies described above.

The Conversion Pipeline

When you drop a file into a browser-based converter, here is what happens:

1. File reading. The browser's File API reads the file from your local filesystem into memory (or into a streaming buffer for large files). The file never leaves your device. There is no upload, no network request, no server involved.

2. Format detection. The tool examines the file's magic bytes (the first few bytes of the file that identify its format) and MIME type to determine the actual format, regardless of the file extension. A file named image.jpg that is actually a PNG will be correctly identified.

3. Decoder selection. Based on the source format and the target format, the tool selects the appropriate decoding pipeline. Simple image-to-image conversions might use the Canvas API. Video conversions use ffmpeg.wasm. PDF operations use pdf-lib or pdfjs-dist. HEIC conversion uses heic2any with a fallback chain to ffmpeg.wasm.

4. Processing. The file is decoded, processed (format conversion, resizing, compression, metadata handling), and re-encoded into the target format. For operations that use Wasm modules, this happens in a Web Worker to keep the main thread responsive.

5. Output delivery. The converted file is constructed as a Blob in browser memory and offered to the user as a download. The file goes directly from memory to the user's filesystem. Again, no server involved.

Handling Large Files

One legitimate concern about client-side processing is memory. A 2 GB video file cannot simply be loaded into browser memory on a device with 4 GB of RAM. Modern browser-based converters handle this through several techniques:

Streaming processing. ffmpeg.wasm can process files in streaming mode, reading chunks from the source file and writing chunks to the output file without holding the entire file in memory simultaneously.

Web Worker isolation. Processing happens in Web Workers, which have their own memory space separate from the main page. If a conversion exhausts its memory allocation, the Worker can be terminated without crashing the page.

SharedArrayBuffer. For operations that require multiple threads (like multi-threaded FFmpeg encoding), SharedArrayBuffer provides shared memory between Workers, enabling parallel processing of video frames.

File System Access API. On supported browsers, the File System Access API allows reading and writing directly to the user's filesystem, reducing the memory footprint by avoiding the need to hold the entire output in memory before downloading.

Why the Upload Model Persists — and Why It Shouldn't

Given that client-side conversion is technically viable for most common format conversions, why do upload-based services still dominate search results and user habits?

Inertia and Discoverability

The upload-to-convert model has been around for over a decade. These services have accumulated years of SEO rankings, brand recognition, and user habits. When someone searches for "convert MP4 to AVI," the top results are dominated by established upload-based services. Browser-based alternatives are newer and less visible.

Revenue Model Alignment

Upload-based converters have a natural revenue model: they can impose file size limits, conversion limits, and speed limits that push users toward paid subscriptions. The server costs provide a genuine justification for charging. Client-side converters, which incur no per-conversion server costs, challenge this model — they can offer unlimited free conversions because the user's own hardware does the work.

Perceived Simplicity

Upload-based converters present a simple interface: upload, click convert, download. Client-side converters present the same interface, but the user might see a progress bar driven by their local CPU rather than a server-side queue. The user experience is similar, but some users distrust processing that happens on their own device because they are accustomed to "the cloud" handling heavy computation.

The Privacy Cost

The most significant problem with the upload model is privacy, and it is not an abstract concern. When you upload a personal document, a private photo, or a confidential business file to a conversion service, you are trusting that service with your data. Most services claim to delete uploaded files after conversion, but you have no way to verify this. The file passes through their servers, their logging systems, and their infrastructure.

Gartner estimates that over 50% of enterprise data will be created and processed outside traditional centralized data centers by 2026. The trend toward edge computing and local processing is driven precisely by organizations recognizing that sending data to remote servers for processing creates unnecessary risk. File conversion is one of the simplest cases where this risk can be eliminated entirely.

What Client-Side Cannot Do (Yet)

Intellectual honesty requires acknowledging the limitations. There are conversion tasks where server-side processing still has advantages:

Extremely long video encoding. Transcoding a two-hour 4K video with complex encoding settings can take 30-60 minutes on a modern laptop. A server farm with hardware encoders can do it faster. However, for most practical video conversion — clips under 10 minutes, social media reformatting, format changes — client-side processing is perfectly adequate.

Formats requiring proprietary codecs. Some codecs are only available as proprietary server-side implementations. This is becoming less common as open-source alternatives mature, but edge cases exist.

OCR and AI-heavy processing. Optical character recognition on scanned documents and AI-based image enhancement benefit from server-side GPU clusters. WebGPU is narrowing this gap, but server-side AI processing is still faster for complex models.

Batch processing at massive scale. Converting 10,000 images is possible client-side but tedious in a browser tab. Server-side APIs are better suited for industrial-scale batch processing.

For the vast majority of individual file conversions — the use case that drives most traffic to online converters — client-side processing is not just adequate but superior. It is faster (no upload/download time), more private (files never leave your device), and unlimited (no file size caps or conversion quotas imposed by server costs).

The Broader Shift

The return of the fat client is not limited to file conversion. Browser-based design tools (Figma), video editors (Clipchamp before its Microsoft acquisition), code editors (VS Code for the Web), and even AI inference (running language models in the browser via WebGPU) all reflect the same trend: the browser has become a capable application runtime, and many workloads that previously required server round-trips can now run locally.

WebAssembly is the enabling technology for this shift. It provides the performance. WASI provides the system access. WebGPU provides the hardware acceleration. Together, they have turned the browser from a document viewer into a general-purpose computing platform.

For file conversion specifically, this means the days of uploading your private files to someone else's server for a task that your own device can perform are numbered. Tools like Fileza.io demonstrate that browser-based conversion across images, video, audio, and documents is not a compromise — it is a better architecture. Your files stay on your device. Processing uses your own hardware. There are no upload queues, no file size limits imposed by server constraints, and no monthly subscription for what amounts to running well-established open-source libraries on your own computer.

The upload-to-convert model is not dead yet, but the technical justification for it is eroding with every WebAssembly improvement, every WebGPU optimization, and every user who discovers that their browser can already do what they have been paying a server to do.