How to trim a video in your browser without uploading it
Drop a video onto the panel above or use the browse link to pick one. The player loads the file straight from your disk through a local object URL, reads its duration and resolution, and builds a strip of sixteen thumbnails by seeking through the file and painting each frame onto a small canvas. Those thumbnails are the timeline: you drag across them to select a region, and the shaded areas at either end show what will be discarded.
Once the start and end points look right, press the trim button. The tool loads ffmpeg compiled to WebAssembly, writes your file into the WebAssembly filesystem, runs a single trim command, and reads the result back as a blob you can preview and download. The video file itself never travels over the network. What does come down the wire is the ffmpeg engine, served from this site rather than a third party network, and it arrives in parts because the core is about 30 MiB and the hosting platform rejects a single file over 25 MiB. Those parts are fetched in parallel, checked against a manifest, and joined into one blob before ffmpeg is handed the result. So your footage stays in the tab, and the only request is for the code that does the work.
When the MP4 trim is lossless and when it is forced to re-encode
For MP4 output the tool always attempts a stream copy first. The command it runs is effectively ffmpeg -ss 12.4 -i input.mp4 -t 18.6 -c copy -avoid_negative_ts make_zero output.mp4, where 12.4 is the start point in seconds and 18.6 is the selected length rather than the end point. Because -c copy moves the already encoded packets into a new container without touching them, this path finishes in a second or two even on a long file and the exported clip is identical in quality to the source. The -avoid_negative_ts make_zero flag shifts the timestamps so the clip starts at zero rather than carrying the original offsets, which is what stops some players showing a blank first second.
The catch with a stream copy is keyframes. A compressed video only carries complete pictures at intervals, often one every two to ten seconds, and every frame between them is described relative to its neighbours. A copy cannot start anywhere except at a keyframe, so an in point at 12.4 seconds with the nearest keyframe at 11.0 gives you a clip that begins at 11.0. That is the price of a lossless cut.
Sometimes the copy produces nothing usable, typically when the input codec does not fit an MP4 container or the selected region contains no keyframe to start from. The tool checks the size of what came back, and if it is under 1000 bytes it deletes that file and runs ffmpeg -ss 12.4 -i input.mp4 -t 18.6 -c:v libx264 -preset veryfast -crf 23 -c:a aac -b:a 128k -movflags +faststart output.mp4 instead. CRF 23 is the standard x264 quality target, veryfast keeps the encode from taking all afternoon, and +faststart moves the index to the front of the file. This path is slower and loses a generation of quality, but it lands the cut exactly on the frame you chose.
Setting exact in and out points with the timeline and the keyboard
Dragging across the thumbnail strip sets both ends at once, and dragging either handle moves one end. Dragging inside the selected region slides the whole selection without changing its length, which helps when the clip is the right duration but starts a beat too early. A tooltip follows the pointer with the time under the cursor, and a badge on the selection shows its length.
Keyboard control is usually faster than the mouse for the last half second. Space toggles playback. The left and right arrow keys step one frame at a time, where a frame is treated as one thirtieth of a second. I sets the start point to the current playhead position and O sets the end point, the same in and out convention used by most editing software. The square bracket keys nudge the start and end by a tenth of a second each press. When a timeline handle itself has keyboard focus, the arrow keys move that handle by 0.1 seconds, or by a full second with Shift held.
MP4 or WebM: which output to choose
MP4 is the default and the only option that can be lossless, for the reasons above. Pick it when you care about quality, when the export needs to be quick, or when the clip is going to a platform or device with narrow format support.
WebM output always re-encodes. The command is ffmpeg -ss 12.4 -i input.mp4 -t 18.6 -c:v libvpx -c:a libvorbis -b:v 1M output.webm, using VP8 video at a fixed one megabit per second and Vorbis audio. A fixed bitrate makes the file size predictable, roughly 125 kilobytes per second of video, but a busy scene at high resolution will look softer than the source. Being a full re-encode in WebAssembly, it also takes considerably longer than the equivalent MP4 copy.
There is no mute or audio-only option in either direction. The trimmed clip carries the original audio track through unchanged on the copy path, or re-encoded to AAC at 128k or Vorbis on the encode paths. If you need a silent clip, strip the track afterwards with a separate tool.
Which files open, and what to do when the preview stays blank
The file picker accepts MP4, WebM, MOV, and AVI, matching on both the MIME type and the file extension. Accepting a file and being able to show it are two different things, though. The timeline, the thumbnails, and the playback preview are all built on the browser's own video element, so the file has to be one your browser can decode. AVI containers and MOV files carrying less common codecs such as ProRes are the usual failures: the file is perfectly valid and ffmpeg could read it, but the preview never loads, so the tool has no duration to build a timeline from and reports a load error. When that happens, convert the source to MP4 first and trim the converted copy; a file that plays in the preview will trim, and one that does not will not.
Very large files are limited by memory rather than by any rule in the tool. The whole file is read into the WebAssembly filesystem, so the tab holds the source and the output at once. Files under about 500 MB are reliable on most machines; a phone will often fail well before that. If an export dies partway through a long recording, trimming a rough region first and refining it afterwards keeps each run within reach.