Initializing... drag & drop files here
Supports: FLV
FLV (Flash Video) was the dominant web video container during the Flash era — introduced in Flash Player 6 in March 2002, used by early YouTube, Hulu, Dailymotion, and Vimeo, and tied to Adobe's Flash Player runtime. Adobe officially discontinued Flash Player on December 31, 2020, and Chrome, Firefox, Edge, and Safari permanently removed Flash support by late January 2021. Yet billions of FLV files still sit in screen-recording archives, e-learning libraries, CCTV exports, and legacy CMS backups. Many were encoded with older codecs (Sorenson Spark, VP6) that are far less efficient than modern H.264 or H.265, so the files are larger than they need to be.
| Property | FLV | MP4 (H.264/H.265) | WebM (VP9/AV1) |
|---|---|---|---|
| Introduced | 2002 (Flash Player 6) | 2003 (ISO/IEC 14496-14) | 2010 (Google) |
| Native browser playback (2026) | None — Flash dead since Jan 2021 | All major browsers | Chrome, Firefox, Edge, Opera; Safari 14.1+ for VP9 |
| Typical video codecs | Sorenson Spark, VP6, H.264 | H.264, H.265 (HEVC) | VP9, AV1 |
| Typical audio codecs | MP3, AAC, Nellymoser, Speex | AAC, MP3, AC-3 | Opus, Vorbis |
| Compression efficiency | Low (Spark/VP6); moderate (H.264) | High (H.264); very high (H.265) | Very high (VP9/AV1) |
| Streaming protocol | RTMP (deprecated) | HLS, DASH, progressive | DASH, progressive |
| Mobile/iOS playback | None natively | Universal | Limited (no iOS Safari for VP9 until 14.1) |
| Recommended in 2026 | Archive only | Default for sharing | Web-optimized delivery |
| Method | Best For | How It Behaves |
|---|---|---|
| Quality Preset | One-click compression | Picks bitrate/CRF behind the scenes; Highest preserves source, Lowest is most aggressive |
| Target file size (%) | Predictable shrink | 50% = roughly half the original; Smart Scaling auto-reduces resolution when needed |
| Specific file size | Hitting hard caps (25 MB, 100 MB) | Calculates the bitrate required to hit the MB target across the full duration |
| Constant Bitrate (CBR) | Streaming with fixed bandwidth | Same bits per second throughout — easy to predict, less efficient on simple scenes |
| Variable Bitrate (VBR) | Best size-to-quality | Spends more bits on motion-heavy scenes, fewer on static frames |
| Constant Quality (CRF) | Visual-quality target | 18 = visually lossless, 23 = default balance, 28 = small with visible loss |
| Constraint Quality | CRF + bandwidth ceiling | CRF target with a hard max-bitrate cap for streaming |
| Trim (Time Range) | Cut dead footage | Re-encode only the selected segment; combine with any method above |
Because most FLV files were encoded with Sorenson Spark or VP6, which were state-of-the-art in 2002–2007 but are far less efficient than H.264 (added to FLV in Flash Player 9 Update 3, December 2007) and dramatically less efficient than H.265 or AV1. Re-encoding a Sorenson Spark FLV with modern H.264 inside the same FLV container typically cuts size 40–60% at matched perceptual quality. If you can change container, converting to MP4 usually gives another 5–15% on top.
For most people: Target file size (%) at 50–60% is the easiest and gives predictable results. For best quality-to-size ratio: Constant Quality with CRF 23 (default) or CRF 26 if you want smaller files. For hitting a hard cap like Gmail's 25 MB or Discord's 10 MB free-tier limit, use Specific file size and enter the exact target. Quality Preset is the fastest if you don't want to think about codec settings.
Yes. Set Trim to Time Range, enter a start time and duration, then pick any compression method. The encoder processes only the trimmed segment, so a 20-minute FLV trimmed to a 4-minute highlight starts ~80% smaller before compression even applies.
CRF 18 is visually lossless (output indistinguishable from source for most content). CRF 23 is the standard H.264 default — small artifacts under careful inspection, fine for general viewing. CRF 28 is noticeably softer but useful for archival of low-priority footage. Anything above 30 shows blocky compression on fast motion. Each +6 CRF roughly halves the bitrate.
Yes, as long as the codec inside is one the player supports — Sorenson Spark, VP6, or H.264 (Flash Player 9 Update 3 and later). XConvert keeps the FLV container; if you specifically need legacy compatibility, pick H.264 as your codec rather than relying on default settings. Note that no current browser will play any FLV without a third-party plugin, so the only modern playback path is a desktop player like VLC or MPV.
If anything downstream still requires the .flv extension (an old Flash-based courseware module, a legacy ingest pipeline), stay in FLV. Otherwise, converting to MP4 is the better long-term move: smaller files at the same quality, universal device support, and HLS/DASH-streamable. For web-only playback, WebM compresses even harder with VP9 or AV1.
For SD source (480p or below), expect 50–70% reduction at visually transparent quality with H.264 + CRF 22 inside the FLV. For HD source (720p/1080p) originally encoded in VP6, 60–80% reduction is realistic. Beyond that, you start trading visible quality — banding in gradients, blocking on motion. Use the Target file size (%) method and preview at 40% first, then push lower if the result still looks acceptable.
Yes — every lossy re-encode introduces some generational loss because the encoder reads already-quantized frames. To minimize damage: use a higher quality setting than the source (CRF 20 if the source was CRF 23), avoid stacking compress→compress cycles, and keep the original archive copy until you've verified the output. If quality matters and the source is salvageable, re-encode straight from the original master, not the FLV.
Yes. Upload as many FLV files as you want and the same compression settings apply to all of them in one batch. There's no file count limit and no sign-up required. Each file processes independently, so a one-off bad frame in one video won't stop the rest.