Cut XviD video by setting start and end times. Trim legacy DivX-era video files. No re-encoding preserves original quality.
Process files in seconds with our optimized servers
Frame-accurate cuts with intuitive timeline controls
Maintain original quality with smart re-encoding
XviD is the open-source MPEG-4 ASP video codec that powered most of the DivX-era AVI ecosystem from 2001 onward — the workhorse behind Kazaa, eDonkey, DC++, and BitTorrent video sharing before H.264 took over around 2010. It still shows up in archived .avi rips, set-top DVD player encodings, and old camcorder exports. Cutting XviD without re-encoding preserves the exact original bytes, which matters when the source is irreplaceable. Cutting XviD is useful for:
For a different output container after cutting, see XviD to MP4 or XviD to MKV. To compress without trimming, see Compress XviD. For the same workflow framed as a trim, see Trim XviD.
| Property | Stream copy (default) | Re-encode (XviD / DivX / MPEG-4 / H.264) |
|---|---|---|
| Speed | Seconds for any file size | Proportional to clip length and codec |
| Quality | Bit-identical to source | Slight loss unless CRF is low |
| Cut precision | Snaps to nearest keyframe (often 10-12s for old XviD) | Frame-accurate |
| Output codec | Stays XviD | Any: XviD, DivX, MPEG-4, H.264, H.265, MJPEG, HuffYUV |
| Audio | Original MP3 / AC-3 / PCM preserved | Re-encoded to chosen codec |
| File size | Proportional to duration kept | Variable by CRF / bitrate |
| Best for | Quick lossless extraction | Frame-accurate cuts, smaller file, codec change |
XviD encoders from the DivX era typically placed keyframes every 250-300 frames (~10-12 seconds at 24 fps), so stream-copy may snap your cut back several seconds from the requested start. Enable re-encode for frame-accurate trims when you need the cut to land on a precise moment.
| Output codec | Quality vs Size | Typical Bitrate / CRF | Best for |
|---|---|---|---|
| XviD (default) | Good / Medium | ~1100-1500 kbps | Keep the original codec, broadest legacy player support |
| DivX | Good / Medium | ~1100-1500 kbps | DivX-certified DVD players and set-top boxes (2003-2010) |
| MPEG-4 (Part 2) | Good / Medium | ~1500 kbps | General legacy playback, reference MPEG-4 ASP |
| H.264 | Excellent / Small | CRF 23 | Modern playback, ~50% smaller at the same visual quality |
| H.265 | Excellent / Smallest | CRF 28 | Newest playback, smallest file, slower encode |
| MJPEG | Frame-independent / Large | ~8000 kbps | NLE scrubbing, frame-by-frame editing |
| HuffYUV | Lossless / Very large | n/a | Editing intermediate, no quality loss between cuts |
Lower CRF = higher quality and larger file. CRF 23 is "visually lossless" for H.264; CRF 28 is the typical default for H.265. If you don't need to keep XviD specifically, XviD to MP4 gives broader device support at similar size.
Yes — stream-copy is the default. The original XviD video bytes and the source audio track are written into a new AVI container without going through a decoder/encoder, so the cut clip is bit-identical to the source segment. The only caveat is keyframe alignment: XviD encoders from the DivX era often placed keyframes every 10-12 seconds, so the cut may snap back a few seconds from your specified start time. Enable re-encode in step 3 for a frame-accurate cut.
Stream-copy mode can only cut at keyframes (I-frames), and XviD encoders that produced most pre-2010 AVI rips placed keyframes far apart — every 250-300 frames is typical, which is 10-12 seconds at 24 fps. Asking to start at 00:01:23 may snap back to 00:01:14 if that's the nearest preceding keyframe. Re-encoding produces a frame-accurate cut at the cost of some encode time.
Yes. Stream-copy preserves the XviD video and the original audio track exactly — if it played in VLC, Kodi, or MX Player before the cut, it plays after. VLC and Kodi have shipped with XviD support since the early 2000s, and MX Player handles XviD natively on Android. Windows Media Player needs a codec pack like K-Lite or LAV Filters, which is the same situation as before the cut.
There's no fixed cap on our side. Cutting runs in your browser session, so the practical limit is your device's RAM and how long you're willing to wait for the file to load. Multi-GB compilation rips and hours-long archived recordings work fine. Stream-copy is fast enough that even 4-hour XviD AVI files cut in well under a minute since no decoding happens. The classic AVI container has a 4 GB single-file limit; OpenDML / AVI 2.0 raises this and most XviD files written after roughly 2003 use OpenDML.
If a specific player, DVD authoring tool, or legacy device requires XviD, keep XviD. Otherwise, MP4 (with H.264 or H.265) is smaller for the same quality, plays natively on every phone and browser, and uploads cleanly to YouTube, Drive, and WhatsApp without re-encode on the platform side. The recommended workflow is: cut first in stream-copy mode (fast, lossless), then run XviD to MP4 on the cut clip — that's roughly 12x faster than transcoding the full source then trimming.
Yes. Cut the XviD to the segment you want, then run XviD to MP3, XviD to WAV, or XviD to AAC on the result. Cutting first is faster because the audio extraction only has to process the clip, not the full source.
Yes. Add multiple trim segments — each pair of start time + duration produces a separate output XviD file. Useful for splitting a multi-episode TV rip into individual files, pulling several music videos out of a compilation AVI, or extracting all the relevant scenes from a long DivX-era download in one batch.
No, by default both the XviD video stream and the audio stream are copied to the output AVI. XviD AVI typically carries MP3, AC-3, or PCM audio — all are preserved bit-identically in stream-copy mode. If you specifically want a silent clip (for over-dubbing, looping background, or muted social posts), set the audio codec option to "no audio" before cutting.
XviD and DivX are both MPEG-4 ASP implementations and produce broadly similar output at similar bitrates. DivX is the original commercial encoder; XviD is the open-source reimplementation that became the de facto free alternative. Pick DivX if you specifically need a DivX-certified DVD player to recognize the file (some checked the FourCC tag), otherwise XviD is the more common modern choice. For anything outside the DivX-era ecosystem, H.264 in MP4 is a better target.