FileForge vs the cloud converters, honestly

When cloud converters are the right answer

A real engineering comparison starts by admitting when the other side wins. Cloud file conversion services solve problems browser-local converters cannot, or at least cannot yet. If your file is bigger than your browser's memory budget (think 20 GB video archives, 10 GB Photoshop files), there is no polite way to handle it in a tab. Cloud servers run with 256 GB of RAM and they do not mind. If you are running a document pipeline that converts ten thousand invoices a day and needs an audit trail with SOC 2 attestation, a serverless cloud converter with a billing-by-the-minute API is the correct architecture. We do not ship that.

Cloud converters also win when the job needs codecs we have not ported. ProRes, DNxHR, DPX image sequences, Final Cut Pro XML. These are real formats used in real industries and the open-source tooling is heavy enough that compiling it to WebAssembly is a real project. Until that work lands, a cloud converter that runs ffmpeg on a fat Linux box is a pragmatic choice.

The third real advantage: integration. CloudConvert has webhooks and Zapier. Smallpdf plugs into Google Drive and Dropbox. If your workflow lives in those tools, server-side conversion has friction you cannot beat with a drag-and-drop page.

When local conversion is the right answer

Most of the time, though, the problem you are trying to solve is: "I have a file, I want it in another format, I would prefer not to ship it to a third party I have to trust." In that case cloud conversion is an oddly structured answer. You pay (usually in attention, sometimes in cash) for a process whose natural form is one function call on your own machine. The reason this feels normal is historical. In 2010, browsers could barely decode a JPG; ImageMagick-on-a-VM was the only option. Browsers caught up. The industry did not.

The privacy gain is real, not abstract. Every file you upload to a cloud converter is a file your laptop remembers forever through its own backups, and that the vendor remembers through theirs. "We delete after 24 hours" is a policy sentence, not a technical guarantee. "The file never left your device, you can confirm in DevTools" is a technical guarantee. The difference matters for private photos, medical records, legal documents, and anything an adversary would consider a nuisance to subpoena.

The cost gain is also real. Our hosting is a static CDN; we can afford to give the service away because it costs us pennies per month in bandwidth. Paid cloud converters have to make margin on every job; their free tiers exist to upsell.

Why we chose local

A FileForge conversion is a function from bytes to bytes. That function belongs in the place where the bytes already are, which is your machine. Moving the bytes somewhere else to apply a function is a workaround for a limitation that does not exist anymore. The browser is a real operating system now; WebAssembly is a real compute target; OffscreenCanvas and WebCodecs are real multimedia APIs. You already downloaded the compute. Use it.

Verifiability is the other half of the story. The "trust but verify" part is not a throwaway line. Every WASM module we ship is pinned by a SHA-256 hash that appears in our public manifest and gets re-checked on every load. You can read the source, compute the hash yourself, and confirm that the code running on your file is the code we advertised. That is an unusual property for a file conversion service.

Where FileForge is weak

No large-file support (the browser memory budget is the ceiling), no server API, no audit log, limited codec coverage compared to a full ffmpeg install, no enterprise contracts, no SLA. For a team that needs those, cloud is the right choice. For an individual who wants to convert a photo and be done with it, we are. For most of everything in between, it depends on whether you would rather trust our SHA-256 or someone else's privacy policy.