MP4 Video Editor

The editor loads FFmpeg.wasm, a WebAssembly build of FFmpeg, from a content delivery network on first use. That package is roughly 25 MB and is cached by the browser afterwards, which is why the first export takes noticeably longer to begin than later ones. Your video file is read into the WebAssembly filesystem in memory, processed there, and written back out as a downloadable file. At no point does the video leave your device.

Your settings become FFmpeg arguments. Trim points turn into seek and duration arguments so only the selected section is processed. Muting drops the audio stream, and a resolution change adds a scale filter.

The key distinction is between stream copy and re-encode. If you are only trimming, the video stream is copied directly, which is extremely fast because the compressed data passes through untouched. Any change to resolution or quality forces a re-encode with the libx264 encoder using the ultrafast preset and the CRF value you set. CRF, the constant rate factor, controls quality inversely: lower numbers mean higher quality and larger files, and the slider runs from 18 at the high-quality end upward.

Progress is reported as a percentage while FFmpeg works.

Take a four-minute screen recording at 1920 by 1080, roughly 180 MB. You want the section from 30 seconds to 2 minutes, downscaled to 720p, with the audio removed.

Set the trim start to 00:30 and the end to 02:00. The panel reports a trimmed duration of 1 minute 30 seconds, or 90 seconds, which is 37.5 percent of the original running time. Enable mute, and select 720p as the resolution.

Because the resolution is changing, this cannot be a stream copy, so the panel shows libx264 with your CRF value rather than stream copy mode. At CRF 23, the standard setting, the output will be re-encoded at 1280 by 720.

The size reduction comes from three compounding factors. The clip is 37.5 percent of the original duration, the pixel count drops from 2,073,600 per frame to 921,600, which is about 44 percent, and the audio track is gone entirely. The result is typically a small fraction of the source file, and the exact output size is displayed when processing finishes.

Had you only trimmed, leaving resolution at original and audio intact, the same job would have used stream copy and completed in a fraction of the time.

Choose CRF according to purpose. Around 18 is visually close to lossless and produces large files. The standard setting of 23 is a good balance for most material. Values in the high twenties and above trade visible quality for smaller files, which suits rough previews and long screen recordings where detail matters less. Each increase of roughly six in CRF approximately halves the bitrate.

If you only need to trim, leave resolution at original and do not adjust quality. That keeps the job in stream copy mode, which is dramatically faster and avoids a generation of quality loss, since the compressed data is never decoded and re-encoded. Note that stream copy can only cut on keyframes, so the actual start point may land slightly off your chosen time.

The main constraint is memory. WebAssembly has a limited address space, so very large files can exhaust it. If an export runs out of memory, trim a shorter section, reduce the resolution, or split the job.

The ultrafast encoding preset keeps processing time reasonable in the browser, which means files are larger than a slower preset would produce at the same CRF. That is a deliberate trade for speed.