Free Video Trimmer & Cutter

Trim video files by setting start and end times. Fast or precise mode.

Your files never leave your device

Drag & drop a video file here

or click to browse · MP4, WebM, MOV, AVI, MKV (max 2 GB)

How It Works

  1. Load a video file: Select any MP4, WebM, MOV, or AVI file from your device, no upload to a server required.
  2. Set trim points: Use the timeline handles or enter exact start and end times to define the clip you want to keep.
  3. Preview your trim: Play the selected segment to confirm the cut before exporting.
  4. Download the clip: Export the trimmed video directly to your device in the original format.

Why Use Video Trimmer?

Most video editing apps require installation, subscriptions, or uploads to cloud servers. This browser-based trimmer processes video entirely on your device using WebCodecs and FFmpeg.wasm, your footage never leaves your machine. It's ideal for quickly cutting intros and outros, isolating clips for social media, removing unwanted segments from recordings, and trimming before sharing. No quality loss from re-encoding unless you choose a different output format, and no file size limits beyond available device memory.

Supported Formats

Cut, trim, split, and why the words matter

In casual speech "trim", "cut" and "split" are interchangeable. In video tooling they describe three different operations. A trim removes content from the beginning and/or end and keeps everything in the middle. A cut in editorial terminology is the boundary between two adjacent shots in a finished edit. A split takes one clip and divides it into two clips at a chosen point. From the user's standpoint, this tool performs a trim, you set a start and an end, and it keeps what's between them.

The interesting question is how it removes the unwanted bytes. Two fundamentally different approaches produce different files.

Fast (stream copy) vs Precise (re-encode)

Stream copy, the "Fast" mode, doesn't look at the picture at all. It opens the container, finds the byte ranges that correspond to the requested time window, copies those bytes verbatim into a new container, fixes up the index and timestamps, and writes the result. There's no decoding, no re-encoding, no quality loss. On a modern machine a 500 MB H.264 file can be trimmed this way in well under a second because the work is essentially file I/O, not arithmetic. The catch: the copy operation can only begin and end on certain frames, specifically I-frames: and those aren't necessarily where you pointed. So the start of the resulting clip may shift forward or back by anywhere from zero to ten seconds, depending on the codec settings used when the file was originally encoded.

The re-encode, "Precise" mode, decodes the entire affected section back to raw pixels, throws away the frames before the requested start and after the requested end, then re-encodes the remainder. This produces a clip that begins and ends exactly at the chosen frame (frame-accurate, in industry terminology) at the cost of a full encode. A full encode is hundreds or thousands of times slower than a stream copy and introduces a generation of compression loss because lossy codecs are not idempotent: encoding, decoding, and re-encoding the same picture does not give you back exactly the same picture. The loss is small at high bitrates but it's non-zero, and it accumulates if the same file is trimmed repeatedly.

The Fast path is correct for the 95% of cases where the user is removing intros, outros, or rough leading and trailing material and doesn't care whether the cut is half a second from where they pointed. The Precise path is the right tool when the cut needs to land on a specific frame, a punchline, a sound effect, a sync mark for a downstream edit.

I-frames, P-frames, B-frames, and the GOP

Every modern video codec (H.264, H.265 (HEVC), VP9, AV1) compresses video by exploiting the fact that consecutive frames are almost the same picture. Rather than encode each frame independently, the codec encodes a small fraction of frames in full and the rest as differences from their neighbours. The full frames are I-frames (intra-coded). The difference frames come in two varieties: P-frames (predicted from earlier frames only) and B-frames (bipredictively coded, they can reference both earlier and later frames). The sequence I, then a run of P and B frames, then another I, is called a Group of Pictures, or GOP. Inside a GOP, no frame can be decoded without reference to the I-frame at the start. Across GOPs there is no dependency: a player can drop into the file at any I-frame and start decoding from there.

This is why stream-copy trimming is constrained to keyframe boundaries. To start a new file at a non-I-frame you'd have to decode the I-frame at the start of the GOP, then decode every P and B frame up to your chosen point, then begin writing, which is exactly what the Precise path does. A typical H.264 file uses a GOP length of two to four seconds. FFmpeg's libx264 defaults to about 250 frames (~10 seconds at 25 fps, ~8.3 seconds at 30 fps). Streaming providers shorten that to two seconds to align with HLS and DASH segment boundaries. H.265 tolerates longer GOPs more efficiently and is often configured at four to ten seconds. VP9 (libvpx) defaults to a maximum keyframe distance of 240 frames. AV1 typically lands in the 2-6 second range. The practical implication: a user asking for a cut at minute 1 second 30 may, depending on what the file was originally encoded with, end up with a stream-copy result that begins anywhere from minute 1 second 24 to minute 1 second 32.

A short history of FFmpeg

FFmpeg was started on 20 December 2000 by Fabrice Bellard, the French computer scientist who'd previously written the QEMU virtualiser and the TCC C compiler. He committed under the pseudonym Gérard Lantau. The name comes from "FF" for fast forward and "mpeg" for the family of codecs it was originally designed to handle. The architecture from the very beginning separated codec implementation (libavcodec) from container parsing (libavformat), which is why FFmpeg has been so easily extended over the years. Bellard handed maintainership to Michael Niedermayer in 2004. The project survived a celebrated fork in 2011 when a group of developers split off a project called Libav over governance disagreements; the two projects re-merged in spirit (if not formally) by 2018, with most of Libav's improvements upstreamed back into FFmpeg.

Today FFmpeg is the silent infrastructure underneath an enormous fraction of the world's video, YouTube, Netflix, VLC, OBS Studio, Audacity, HandBrake, Plex, and most professional broadcast pipelines use it somewhere in their stack. The current stable release as of 2026 is in the 8.x series. The licence is dual LGPL-2.1-or-later or GPL-2.0-or-later depending on which optional components are enabled at compile time.

FFmpeg.wasm, FFmpeg in the browser

In November 2020 a Taiwanese engineer named Jerome Wu: already known for the Tesseract.js port of the Tesseract OCR engine, published the first release of FFmpeg.wasm, a WebAssembly compilation of FFmpeg that runs entirely inside the browser. He announced the project on 4 November 2020. By 2026 the project has matured significantly, with the current release in the 0.12 series and active community forks. The npm package now bundles the core WebAssembly binary, a JavaScript wrapper that handles message-passing between the main thread and the worker thread that runs the WASM, and a virtual file system that lets the user move files in and out using ordinary JavaScript Blob and File objects.

The project has one notorious requirement that catches every developer who tries to deploy it for the first time. FFmpeg.wasm uses SharedArrayBuffer, the JavaScript API for sharing memory between the main thread and worker threads. After the Spectre and Meltdown CPU vulnerabilities were disclosed in 2018, browsers tightened the conditions: the page must be served with two specific HTTP headers, Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp, and every cross-origin resource on the page must either opt in via CORS or come from the same origin. Without those headers, SharedArrayBuffer is undefined and FFmpeg.wasm won't initialise. Chrome enforces this strictly; Firefox and Edge follow Chrome; Safari joined from version 15.2 onwards.

Container formats

A container is the file wrapper. It doesn't encode the picture; it packages encoded pictures and audio together with timing and metadata.

Browser video APIs, what's actually available

The HTML5 <video> element became a W3C Recommendation on 28 October 2014, after roughly a decade of development. Before HTML5, embedding video meant Adobe Flash or Microsoft Silverlight. The element by itself has no editing API, there's no video.trim(start, end) method, no video.cut(), no built-in way to extract a segment. To do anything beyond play, pause and seek, the developer must reach for a lower-level API or compile FFmpeg into the page.

Media Source Extensions (MSE) is a W3C specification that lets JavaScript construct the byte stream that feeds the <video> element. Reached Candidate Recommendation in 2014; used in production by YouTube as early as September 2013 and by Netflix from June 2014. Its primary use case is adaptive streaming (it doesn't expose decoded frames, so it can't perform a re-encode on its own. WebCodecs is the lower-level alternative) exposes the browser's built-in video and audio codec implementations directly to JavaScript, with VideoDecoder and VideoEncoder interfaces. WebCodecs shipped officially in Chrome 94 on 21 September 2021 after an origin trial in Chrome 93, and has since reached Firefox and Safari. The current state of the art is for tools to use WebCodecs when it's available and the codec is supported, and to fall back to FFmpeg.wasm otherwise. This tool uses both.

Social-platform length limits, why people open trimmers

A great deal of the demand for browser-based trimming comes from preparing videos for social-platform upload, each with its own maximum length:

These numbers shift constantly as platforms iterate, but the general pattern of "platform X will reject your upload if it exceeds Y minutes" is durable, and is one of the most common reasons an end user opens a trimmer in the first place.

When a desktop editor is the better tool

For users for whom a browser trimmer is insufficient, the professional ecosystem revolves around a few established desktop applications. Apple ProRes is a family of intermediate codecs introduced by Apple in April 2007 alongside Final Cut Studio 2, designed for editing, not delivery. Final Cut Pro, originally released in 1999 by Macromedia and acquired by Apple a year later, was rebuilt and re-released as Final Cut Pro X on 21 June 2011; macOS-only and the standard editor in much of the documentary and broadcast world. DaVinci Resolve, originally a high-end colour-grading system, was acquired by Blackmagic Design in 2009 and progressively rebuilt into a full editing/audio post/visual effects/grading suite, available for macOS, Windows and Linux, with a free base version that has changed the economics of the editing market substantially. Adobe Premiere Pro is the third major player and dominates much of the film and TV industry. None of these is appropriate for the user who wants to remove the first ten seconds from a phone-recorded clip before posting it to TikTok, which is exactly the gap a browser trimmer fills.

Why "no upload" matters here specifically

The single most important property of a browser-based video trimmer is that the file does not leave the user's machine. The video data is loaded from a File input directly into JavaScript memory, processed by WebAssembly inside the browser process, and the result is offered as a download. There's no upload, no third party that can read the file, no cloud bill that scales with user count, no data retention policy to write or audit. For sensitive content (recorded meetings, personal footage, anything that couldn't be uploaded to a third party for legal or contractual reasons) that's the only architecture that makes sense.

The downside is that the user pays the compute cost. A trimmer that runs on a server farm can re-encode a 4K clip in a few seconds because it has access to GPU encoding hardware; the same operation in FFmpeg.wasm running in software on a laptop CPU might take a minute or two. The Fast (stream copy) path largely sidesteps this by avoiding the encode altogether, which is why it's the right default for almost every casual trimming use case. The Precise (re-encode) path is the right default only when the user explicitly needs frame accuracy at the cost of waiting.

More questions

Why is my Fast trim starting earlier or later than I asked for?

Because Fast mode (stream copy) can only begin on a keyframe (I-frame), and the nearest keyframe before your requested start may be up to a full GOP earlier, anywhere from 2 to 10 seconds depending on how the source was encoded. If you need the cut at a specific frame, switch to Precise mode, which re-encodes and lands exactly on the chosen frame at the cost of a longer wait and a small generation of compression loss.

Why is the audio out of sync after my Fast trim?

Usually because the cut point landed inside a video GOP and the audio frame at that timestamp doesn't align with a video keyframe. Fast mode shifts the video start to the nearest keyframe but may carry the audio timestamps unchanged, producing an offset. The standard FFmpeg fix is the -avoid_negative_ts make_zero flag, which re-bases all timestamps so the first one is zero. If sync is critical, Precise mode resamples the audio to align with the new start and avoids this class of problem.

Can I export to a different format than the input?

For format conversion, the Video Converter tool is purpose-built and exposes more options. The trimmer is optimised for the same-codec, same-container case (Fast mode preserves the original encoding entirely) or for re-encoding to a small set of web-friendly outputs in Precise mode. Re-encoding always costs CPU time and a generation of quality loss; if you only need to change the container without re-encoding the picture, an ffmpeg -c copy equivalent is the right tool.

Why does AVI input work but AVI output doesn't?

AVI predates most modern codec features (B-frames are awkward, audio sync is fragile beyond 4 GB, the index format is limited), and modern tooling generally treats it as a legacy input format only. Inputs in AVI are read fine; outputs default to MP4 or WebM, which are the actively maintained ISOBMFF/Matroska families and play in every modern browser and player.

Related Tools

Video Converter

GIF Maker

Video to Text

Audio Trimmer