How it works

The short version

WebAssembly lets compiled code — C, C++, Rust — run inside a browser tab at roughly native speed. Over the last few years, most of the important open-source media and document libraries have been compiled to target it. That means a browser can now do work that used to require either a desktop install or a server.

Filery is built entirely on that. Each tool loads the engine it needs, runs it in a background thread so the page stays responsive, and writes the result straight to your downloads.

What runs what

Area	Engine	Notes
Video, audio	WebCodecs, with FFmpeg (WebAssembly) as fallback	WebCodecs is hardware-accelerated where the browser supports it
PDF	pdf-lib, PDF.js, qpdf	All permissively licensed — see the licensing note below
Images	MozJPEG, libwebp, libavif, libjxl, Oxipng	The same encoders used in professional pipelines
Archives	fflate, libarchive	ZIP natively; RAR, 7z and tar variants via WebAssembly
OCR	Tesseract 5	Language data downloads on demand
On-device AI	ONNX Runtime Web	Speech, transcription, matting, upscaling

Handling files bigger than memory

The naive way to process a file in a browser is to read the whole thing into an array. That falls over somewhere around two gigabytes, which is the practical ceiling for a WebAssembly heap.

Instead we use the Origin Private File System — a real filesystem the browser gives each site, isolated from everything else and invisible to other pages. Large files are streamed through it in chunks, so memory stays flat regardless of the file size. It is also why a batch of three hundred images does not behave any differently from a batch of three.

Why we avoided some libraries

There are more capable options than the ones we chose. MuPDF and Ghostscript both produce better PDF compression than anything we can offer. We did not use them because both are licensed under the AGPL or GPL, which would require open-sourcing this entire site under the same terms. That is a legitimate licence and a legitimate choice for other projects, but it is not compatible with how this one is built.

Similarly, the best-known browser background-removal package is source-available rather than genuinely open source. We assembled an equivalent from permissively-licensed parts instead.

The consequence is that our PDF compression is honestly weaker than a server running Ghostscript. We would rather say that plainly on the tool page than quietly under-deliver.

Where this approach genuinely loses

Client-side is not universally better, and pretending otherwise would be silly.

• Heavy video transcoding is slow. Re-encoding a long 4K file will take substantially longer than a server farm would. Cutting and trimming are fast because they often avoid re-encoding entirely, but a full transcode is bounded by your own hardware.
• Some conversions cannot reach full fidelity. PDF to Word is the clearest example. Doing it properly needs layout analysis that has no browser-capable equivalent, so we do a good job on simple documents and say so on the ones where we cannot.
• First use of a heavy tool has a download. The engine has to arrive before it can run. It is cached afterwards, but the first run is slower.
• Old devices struggle. A five-year-old phone will find neural upscaling hard going. There is no server to offload to.

We think the trade is worth it for almost everything people actually use these tools for. But you should know which side of the trade you are on.