When we started building applications that handled documents, images, videos, and audio files, we kept running into the same problem.
Almost every file conversion service worked like this:
Upload your file.
Wait while it reaches a remote server.
The server processes it.
Download the converted file.
Hope your file is deleted afterward.
At first, this didn't seem like a big deal. It's how most online converters have worked for years.
But after integrating several of them into our workflow, we started asking ourselves a simple question:
Why does every file have to leave my computer just to change its format?
The Privacy Problem
Imagine converting:
your passport
tax documents
contracts
customer data
private photos
business presentations
Every one of these files is uploaded to someone else's infrastructure.
Most services promise that files are deleted after a few hours.
Some say 24 hours.
Some say 48 hours.
Some don't even mention how long files are stored.
The reality is simple:
If your file reaches a server, you no longer have complete control over it.
Even if the company is trustworthy, uploading sensitive files introduces additional risks that simply don't exist when everything happens locally.
The Performance Problem
Uploading large files is slow.
A 2 GB video doesn't start converting immediately.
First, it needs to be uploaded.
Then processed.
Then downloaded again.
For many users, the upload takes longer than the actual conversion.
If your internet connection is unstable, you start over from scratch.
We thought there had to be a better approach.
Modern Browsers Are More Powerful Than We Think
A few years ago, building a browser-based converter would have sounded unrealistic.
Today, browsers support technologies like:
WebAssembly
File API
Streams API
Canvas API
OffscreenCanvas
Web Workers
Combined together, they make it possible to process surprisingly complex files without relying on a backend for the conversion itself.
The browser has become much more than a document viewer.
It's a capable application platform.
What If Files Never Left Your Device?
That question became the starting point for our project.
Instead of asking users to upload files, we decided to perform conversions directly inside the browser whenever possible.
That changes the workflow completely.
Instead of:
Your Computer
↓
Remote Server
↓
Conversion
↓
Download
The process becomes:
Your Computer
↓
Browser
↓
Conversion
↓
Done
No waiting for uploads.
No waiting for downloads.
No wondering where your files are stored.
The Challenges
Of course, building everything inside the browser wasn't easy.
Different file formats require different processing pipelines.
Images behave differently from videos.
Videos behave differently from PDFs.
Audio formats have their own quirks.
Memory usage also becomes important because everything runs on the user's machine.
Some browsers impose limits.
Mobile devices have much less RAM than desktop computers.
Every optimization matters.
The Result
After many iterations, we built a browser-first converter that handles many common file conversions without sending the files to our servers.
The biggest difference isn't the interface.
It's what doesn't happen.
Your files stay where they already are—on your own device.
That means:
better privacy
faster processing for many conversions
no large uploads
no waiting for server queues
fewer concerns about temporary file storage
Lessons We Learned
Building browser-first software changed how we think about web applications.
Not every task belongs on a server anymore.
Modern browsers are capable of much more than many developers realize.
If you're building applications that work with user files, it's worth asking whether the processing really needs to happen remotely.
Sometimes the fastest, simplest, and most privacy-friendly solution is to keep everything local.
Try It Yourself
If you're curious about what browser-based file conversion looks like in practice, we've made our implementation publicly available.
You can try it here:
We're still improving it every week, adding support for more formats and optimizing performance across different browsers.
We'd love to hear what you think and what file formats you'd like to see supported next.
Top comments (7)
I'd love to hear more about the 2 GB video case. Skipping the upload is a clear win, but converting something that size in the browser means working inside tight memory limits, and mobile makes them tighter. Are you streaming the file through the converter in chunks, or does it all have to fit in memory, so really big videos are still out of reach? For documents and images the local approach already wins outright, and those cover the passport and contract examples that matter most for privacy anyway.
You've got it exactly right. Our in-browser media path uses ffmpeg.wasm, which loads the input into the WASM heap before it runs — there's no chunked streaming through the encoder, so the effective ceiling is roughly a couple hundred MB on desktop and much less on mobile. A 2 GB video simply won't fit in the browser; in-browser media is really for small-to-medium clips, and that's where skipping the upload pays off cleanly. For files that genuinely exceed what the browser can hold, we don't just fail — they're handled by a heavier engine in an isolated, sandboxed step, and the files are wiped automatically within the hour, nothing retained. Longer term, real streaming transforms in the browser (WebCodecs + chunked demux/mux) are the direction that could push even large video fully local — that's what we're building toward next.
Browser-based conversion is underrated from a privacy standpoint. The UX challenge is making the local processing boundary obvious enough that users understand the file is not quietly leaving the machine.
You've put your finger on exactly what we care about. Local-first is the default — whenever a conversion can run in the browser, it does, and the file never leaves the machine. The UX challenge, like you say, is making that boundary visible rather than something users have to take on faith. The direction we're taking is per-job transparency: signal up front whether a given conversion is running locally, and show it while it's happening, instead of a vague global "we're private" claim. And for the cases that genuinely need a heavier engine, that step is isolated and the files are auto-deleted within the hour — nothing is stored long-term. If you've seen patterns that communicate a "this stayed on your machine" boundary well, I'd genuinely like to steal them.
Per-job transparency is the right pattern. I would rather see a clear local/cloud badge at the moment of conversion than a broad privacy promise in the footer. Users trust boundaries more when they can see them at the exact decision point.
How did you handle cross-browser compatibility for the file converter, especially with varying support for APIs like File System Access? I'm following your work for more insights on this topic, would love to hear about any challenges you faced.
Good question — and the short version is we deliberately don't rely on the File System Access API, precisely because of its uneven support (Chromium-only; Firefox and Safari don't implement the writable/picker side). Building the core flow on it would have made the feature Chrome-only. Instead we stick to the lowest-common-denominator primitives that work everywhere: the plain File API via and drag-and-drop, URL.createObjectURL, Canvas toBlob for image encoding, and ffmpeg.wasm for media. Nothing there needs FSA. The real cross-browser pain was ffmpeg.wasm: WASM feature-detection, memory ceilings that differ wildly between desktop and mobile, and Safari being the strictest. Our answer is graceful degradation — we feature-detect and wrap the browser path in a try/catch. And for the rare cases the browser can't handle, the fallback runs in an isolated, sandboxed step and the files are wiped automatically within the hour — nothing is kept around. So the user always gets a result, safely.