Edit Video Without Uploading It Anywhere

You can trim, crop, compress and convert a video inside a web page without the file ever leaving your computer. The mechanism is a C library compiled to WebAssembly: FFmpeg, the same engine sitting underneath most desktop video software, built into a binary your browser downloads once and then runs on your own CPU. Your file is read into browser memory through the ordinary file picker, processed there, and handed back as a download. There is no upload bar because there is nothing to upload. The costs are real and worth knowing before you start: your laptop does the encoding, so a long clip takes real time, and very large files hit a memory ceiling that a server would not have. VidClip works this way. So do several other tools, and they are named further down with what each one actually does.

That is the short version. The rest of this page is the architecture, the trade you are making when you choose it, an honest table of who processes locally and who does not, and the cases where handing your file to a server is still the better call.

What does "online video editor" usually mean for your file?

For most of the last fifteen years it meant exactly one thing. You picked a file, the browser streamed every byte of it to a machine somewhere else, that machine put your job in a queue, a copy of your video sat on its disk for some retention window, and eventually you downloaded a result. The editing interface was a remote control. The work happened on hardware you would never see, on a copy of your footage you no longer controlled.

That architecture is still the default, and the marketing language does not distinguish it from the alternative. "Edit video in your browser" is used by both kinds of tool, because both kinds genuinely run their interface in a browser. The difference is where the pixels get crunched.

Kapwing is upfront that it is the server kind. Its own editor page describes the product as "cloud based, which means your videos are wherever you are," tells you to "upload a video from your device," and states that on a free account "all exports from within the online video maker will contain a watermark." Clideo's FAQ gives itself away more quietly: the premium tier, it says, "lets you upload bigger files." A file size limit that scales with your subscription is a billing decision about someone else's storage, not a constraint of your machine.

Neither of those is a criticism. Both are competent products doing a legitimate thing. But if your reason for searching was that you would rather a rough cut of an unreleased product demo, a medical scan, a client recording or a family video not be copied onto infrastructure you do not control, you need a way to tell the two architectures apart. Four signals do it reliably:

• The progress indicator. A tool that uploads has to show you an upload phase, usually a percentage that tracks your connection speed rather than your CPU. A local tool goes straight to encoding.
• The behaviour with the network off. This is the definitive test, and you can run it in ten seconds. More on it at the end.
• The size cap. A cap in the multiple gigabytes is a server tell. As you will see below, browsers cannot address that much memory in the first place.
• The privacy page. Local tools have almost nothing to say about file retention, because there is nothing retained. Server tools have a retention window, and a good one publishes it.

How can a browser run FFmpeg at all?

The thing that changed is WebAssembly. MDN describes it as "a low-level bytecode format originally designed for the web," and is explicit about the point of it: it "is not primarily intended to be written by hand, rather it is designed to be an effective compilation target for source languages like C, C++, Rust." The goal, per the same MDN guide to WebAssembly concepts, is that code "can be executed at near-native speed across different platforms."

That matters here because the video tooling everyone already relies on is written in C. The FFmpeg project calls itself "the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything," and it is what the desktop apps, the server farms and the command lines you have read about all sit on top of. Compile that C to WebAssembly with Emscripten and you get a binary a web page can fetch and execute.

The full path a file takes on a page like this one is short, and it has no network hop in the middle of it:

1. You choose a file with a standard file input or a drop target. The browser's File API hands the page an object representing bytes on your disk, which the page can read but cannot send anywhere on its own.
2. Those bytes are written into a virtual filesystem that lives inside the WebAssembly module's memory.
3. FFmpeg runs against that virtual filesystem, in a web worker so the interface stays responsive, with the same argument list you would type at a terminal.
4. The output file comes back out of the virtual filesystem as a Blob, and the page turns it into a download link.

On VidClip the compiled core is roughly 11 MB. It loads on first use rather than on page load, and the browser caches it afterwards, which is why the first tool you open in a session pauses briefly before it starts and every tool after that does not. The server's entire job is serving that static file and the page around it.

The sandbox is doing real work here too. WebAssembly in a browser is a memory-safe, sandboxed execution environment that enforces the same origin and permission policies as everything else on the page. FFmpeg compiled this way cannot reach your filesystem. It can only see the bytes you explicitly handed it.

What is genuinely slower when nothing uploads?

Four things, and pretending otherwise would be dishonest.

Cold start. That 11 MB core has to arrive once. On a fast connection it is a couple of seconds and then it is cached. On a bad hotel connection it is the slowest part of your first edit.

Raw encoding throughput. A server-side service runs on a machine chosen for the job, often with hardware encoders. You are running on whatever is in your laptop, through a sandboxed virtual machine, usually without GPU acceleration. Near-native is not native. Expect a re-encode to take a meaningful fraction of real time on a long clip, and expect a laptop on battery to be slower than the same laptop plugged in, because the CPU throttles.

Threads, which are not free on the web. FFmpeg gets much of its speed from using every core you have, and in a browser that requires shared memory between workers. MDN is blunt about the condition: "to use shared memory your document must be in a secure context and cross-origin isolated," which in practice means the page must be served with Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers. Sites that have not set those headers, or that need to embed third-party content the headers would break, end up on a single-threaded build. It works. It is slower.

A hard memory ceiling. This is the real limit, and it is not a policy choice anyone can lift. WebAssembly currently uses 32-bit pointers, so as the V8 team put it when they raised the limit, "4GB is the most we can possibly hope to be able to access", because "the new 4GB limit is the largest amount of memory possible with 32-bit pointers, which is what WebAssembly currently supports." A future 64-bit memory model will change that. Today it does not.

The practical ceiling sits well under the theoretical one, because the input file, the output file and the encoder's working buffers all share that single address space at the same time. A tool that let you load a file right up to the limit would simply crash when it tried to write the result. That is the honest reason VidClip caps free input at 200 MB rather than at a rounder marketing number, and why Pro's cap is described as your browser's memory rather than as a figure we invented.

What you get in exchange is worth weighing rather than dismissing. A 400 MB screen recording on a typical home upload does not travel instantly. The bytes go up, then the result comes back down, and on an asymmetric connection the upload alone can take longer than the encode you were waiting for. Local processing deletes both halves of that round trip, removes the queue entirely, and works the same at midnight as it does at peak. It also means the operations that never re-encode at all are effectively instant. A stream copy trim moves compressed data between containers without decoding it, which is why lossless trims snap to keyframes and why they finish in a moment regardless of how long the file is.

If your goal is a specific output size rather than raw speed, the arithmetic is the same locally as it is anywhere else, and it is written out in full in compressing a video to an exact file size. The compressor here applies it on your own machine.

Which tools actually process locally?

VidClip is not alone at this, and the table would be dishonest if it implied otherwise. Every row below reflects what each tool states on its own pages, checked on 18 August 2026. Where a tool does not state something, the cell says "not stated" rather than a guess. Specifications on live products change without notice, so re-check anything you are relying on.

Tool	File uploads?	Account required	Watermark on free output	Size cap
VidClip (this site)	No	No	Yes, small corner mark on video exports	200 MB free
QuickEditVideo	No, "your files never leave your device"	No, "no signup required"	not stated	not stated
edit.video	No, "we don't upload any data"	No, "no account to create"	No, "no watermarks"	not stated
wide.video	No, "no server uploads"	No, "no logins, no passwords required"	No, "no watermarks"	not stated
Kapwing	Yes, "cloud based"	not stated	Yes, free exports "will contain a watermark"	not stated
Clideo	Yes, premium "lets you upload bigger files"	Optional, unregistered users "finish editing in one go"	Yes, premium "doesn't add watermarks"	not stated

Two notes on our own row, because a comparison table where the author's product wins every column is not a comparison table.

VidClip's free tier does put a small mark in the corner of video exports. Several of the local tools above genuinely do not, and if a clean export with no account and no payment is the only thing you need, they are a straightforward answer. What Pro buys is the removal of that mark and of the 200 MB cap, plus compression to an exact target size, instant lossless trim and mute, contact sheets, and a settings advisor. The full breakdown is on the Pro page. Audio-only output such as MP3 has nowhere to put a visual mark and is unmarked on the free tier.

The second note is a genuine exception to this entire article. Transcription is the one tool on this site where something does leave your machine. The browser extracts the audio locally and downsamples it to mono before sending speech only for recognition, so no video is transmitted, but audio does go to a server. Useful speech models run to hundreds of megabytes, which is not a download you can reasonably put in front of someone who just wants a transcript. Every other tool in the catalogue stays entirely on your device.

When is a server-side tool the right choice anyway?

Local processing is not a universal answer, and the honest cases against it are easy to list.

Files past the ceiling. Multi-gigabyte camera originals, long-form interviews, anything where the source alone approaches browser memory limits. A server has as much RAM as it was paid for.

Long renders you do not want to babysit. Local work needs the tab open and the machine awake. If a render is going to take twenty minutes, a queue you can walk away from is a feature, not a compromise.

Collaboration and shared assets. Several people editing one project, stock libraries, brand kits, comment threads, version history. Those need shared state, which needs a server by definition.

Anything that requires a large model. Automatic captions, background removal, object tracking. Some of this is starting to run on device. Much of it still cannot, and a tool that pretends otherwise is either shipping an enormous download or quietly uploading anyway.

The reasonable position is to match the architecture to the job. For the ordinary work of making a file smaller, shorter, squarer or a different format, which is most video work most days, there is no longer a technical reason for your file to travel.

Frequently asked questions

Can a browser edit video offline?

Yes, once the page and its WebAssembly core have loaded and been cached. Nothing in the trim, crop, resize, rotate, speed, compress or convert path needs the network, because the encoder is already on your machine and your file never had to travel in the first place. Load a tool, turn off your Wi-Fi, and run it. The one exception on this site is transcription, which sends extracted audio for recognition and therefore needs a connection.

Is in-browser editing slower?

For the encoding step, usually yes. Your CPU is doing work a purpose-built server would do faster, often without hardware acceleration and sometimes on a single thread. For the whole task, frequently no. There is no upload, no download of the result, and no queue, so on any file large enough for transfer time to matter the local route can finish first. Operations that copy compressed streams instead of re-encoding, such as a lossless trim, are effectively instant either way.

What file size can a browser handle?

Less than a server, and the limit is structural rather than a matter of policy. WebAssembly addresses memory with 32-bit pointers, which caps a module at 4 GB, and in practice the usable figure is far lower because the input, the output and the encoder's buffers all occupy that same space at once. Long clips at high resolution consume it quickly. VidClip's free tier accepts inputs up to 200 MB for exactly this reason, and Pro lifts the cap to whatever your browser can actually hold, which depends on your machine.

Which online editors don't upload your video?

Based on each tool's own claims as of 18 August 2026: QuickEditVideo, edit.video, wide.video and VidClip all state that processing happens on your device. Kapwing and Clideo are server-side by design. Do not take any of that on faith, including ours. The test in the next section settles it in seconds, and it is the only verification that does not depend on trusting a marketing page.

Verify it yourself

Open any tool on this site, pick one from the catalogue, and let the page finish loading. Then turn off your Wi-Fi or pull the ethernet cable. Now load your video and run the edit. It completes, and the finished file downloads, because the only machine involved was already yours.