How we built free video tools that never upload your file

GrabCast — Thu, 08 Oct 2026 05:20:56 +0000

Disclosure: I build GrabCast, the site used as the example here. This post is about the engineering, and the only link to the product is at the end.

Most "free online video tools" work like this: you upload your file, a server processes it, you download the result. That is simple to build, and it means a stranger's server holds your video. For a lot of people (a family clip, a client's draft, a scan with an address on it) that is a bad trade.

We wanted tools where the file never leaves the device. This is what we learned building them, including the parts that are still annoying.

The basic architecture

A browser tool that never uploads has three jobs:

Read a local file the user picked, without sending it anywhere.
Transform it using code that runs in the page.
Hand the result back as a download.

Step 1 is trivial. <input type="file"> or drag-and-drop gives you a File, which is a handle to bytes on the user's disk. Nothing leaves the machine unless your code sends it. Step 3 is also easy: create a Blob, make an object URL, trigger a download.

Step 2 is where the work is, and for video it is heavy.

Option A: ffmpeg compiled to WebAssembly

ffmpeg is the standard tool for video. It is written in C. Compiled to WebAssembly (via Emscripten), you can run it inside a web page. That gives you almost every codec and filter you already know: scale, crop, pad, concat, audio extraction, and so on.

This is what our video crop and resize tool uses for export. You pick 9:16, 1:1, 4:5 or 16:9, and the page builds an ffmpeg filter graph. For "fit, no crop" it scales the video to fit, blurs a scaled copy as the background, and overlays the sharp video on top. The output is an MP4 with H.264 video and AAC audio at 128 kbps.

The costs are real:

Download size. The ffmpeg WebAssembly core is about 32 MB. We load it on first use and let the browser cache it, so the first export feels slow and later ones don't. We say this on the page instead of hiding it behind a spinner, because a silent 32 MB download on mobile data is rude.
Speed. WebAssembly ffmpeg is much slower than a native binary, particularly for software H.264 encoding. A short vertical clip is fine. A long 4K video is not a good fit.
Memory. This is the one that bites. The input file is copied into the WebAssembly virtual file system, the output is written to memory, and both need to fit. The browser also caps how much memory a tab may use. On our crop tool page we tell users plainly that files over roughly 250 MB on a phone or 1.5 GB on a computer may fail, and that trimming first helps. Those are guidelines, not guarantees.

If you ship something like this, put the limits where users can see them before they pick a file. Nothing erodes trust faster than a progress bar that dies at 94%.

Option B: WebCodecs

WebCodecs (VideoDecoder, VideoEncoder, AudioEncoder and related classes) lets a page use the browser's own codecs, often with hardware acceleration. For a transformation like re-encoding, this can be dramatically faster than software encoding in WebAssembly, and it does not need a 32 MB download.

The tradeoffs:

You only get the codecs the browser ships. H.264 support in VideoEncoder, for example, varies by browser, platform and hardware.
You have to do the muxing yourself. WebCodecs gives you encoded chunks, not a finished MP4. You need a muxer library (or your own) to put chunks into a container.
Filters are your job. Scaling and cropping can be done with canvas or VideoFrame, but compositing something like a blurred background means writing the drawing code.
Feature detection is mandatory. Check that the API exists and that your exact config is supported before you commit to that path:

async function canEncodeH264(width, height) {
  if (typeof VideoEncoder === "undefined") return false;
  const { supported } = await VideoEncoder.isConfigSupported({
    codec: "avc1.42001f", // H.264 Baseline
    width, height,
    bitrate: 4_000_000,
    framerate: 30,
  });
  return !!supported;
}

Choosing between them

The rule of thumb we use: use WebCodecs when the transformation is a simple re-encode and the browser supports the exact config; use ffmpeg.wasm when you need filter graphs, odd containers, or consistent output across browsers. Both are better than uploading when the goal is privacy, and neither is free in engineering time.

Proving "never uploads"

Saying it is easy. Users should be able to verify it. Three habits:

Keep processing code and network code visibly separate. In our tools the file is only passed to the processing function. There is no code path that attaches it to a request.
Tell people to open the Network tab. Drop a file, run the tool, and look for a request carrying your file. If a feature does need a server (some of our AI text features do), label it and say exactly what is sent. Our AI tools that need a server send only the text or image the user provides.
Be deliberate about third-party scripts on tool pages. Ads and analytics are the usual suspects. Our own analytics beacon sends only the page path, the referrer and a country code, never file names or contents. The site does show ads on some content pages, so ad units are kept out of the tool area itself.

We also published the privacy model in plain language on the homepage, because "your file never leaves your device" is a claim you want to be easy to check and hard to quietly break.

The boring parts that matter

Progressive enhancement. Show a real error when WebAssembly or a needed API is missing, not a blank page.
Cancel and cleanup. Free the WebAssembly file system after each job. A tab that leaks 800 MB looks like a crash.
Small things users notice. Preserve audio, keep rotation metadata, don't re-encode if a stream copy would do. Filenames should come out sane.
No watermark. This is a product decision, but it is also a trust one: if the tool is free, the output should be unmarked.

Takeaways

Client-side video is practical for short clips and modest sizes, and it is a real privacy win.
ffmpeg.wasm gives you power and compatibility, and costs you download size, speed and memory.
WebCodecs gives you speed, and costs you filters, muxing and compatibility work.
Tell users the limits up front, and make "no upload" verifiable.

If you want to see the tool this article describes, it is at https://grabcast.click/crop-video.html?utm_source=devto&utm_medium=community&utm_campaign=launch-2026q4 (I built it; it is free and there is no sign-up). I'd like to hear about any browser or codec combination that breaks.

This post was drafted with AI assistance and reviewed and edited by me for accuracy.

DEV Community: GrabCast