Most people did not come to our video compressor asking for a codec lesson. They came with a number their video had to fit.
Across 424 production compression jobs, 306 used exact target-size mode, 115 used a quality preset, and only three chose resolution as the primary mode. The median requested target was 20 MB. This does not tell us which setting is universally best, but it does tell us what problem users were actually trying to solve: make this file fit a hard limit.
This study shows the full aggregate, how we calculated it, what changed because of it, and which claims still need a controlled experiment.
Quick findings
- 72.2% of jobs chose exact target size. Presets accounted for 27.1%; resolution mode accounted for 0.7%.
- The median requested target was 20 MB. Among target-size jobs, 104 asked for a result between 10 and 20 MB.
- 401 jobs completed and 20 failed. Excluding three jobs still processing, the settled-job success rate was 95.2%.
- 80.6 GB went in and 22.8 GB came out. That is 57.8 GB removed in aggregate, not a promise that every file will shrink by 71.7%.
- MP4 to MP4 dominated. It accounted for 357 jobs; MOV to MP4 accounted for another 52.
- Repeat use was visible but not universal. Seventy-five signed-in users ran a job, and 28 of them ran at least two.
What 424 real compression jobs asked for
Exact target size was chosen almost three times as often as a preset. The same jobs reduced 80.6 GB of source video to 22.8 GB, but that aggregate is not a promise for any one file.
| Metric | Observed result |
|---|---|
| Target-size demand | 306 of 424 jobs; median target 20 MB |
| Settled-job success | 401 of 421 settled jobs (95.2%) |
| Aggregate bytes removed | 80.6 GB to 22.8 GB (71.7% removed) |
Source: Aggregate production jobs, 5 Sep–16 Oct 2026 (n=424) · Method: Admin export grouped by final job status and selected compression mode; byte totals were summed before rounding to one decimal place.
About the dataset
The dataset is an aggregate export of VidSmaller production jobs created from 5 September through 16 October 2026. It contains 424 jobs and their final or current state, selected compression mode, input and output format, byte totals, and target-size setting when present.
No file names, videos, user identities, IP addresses, or job identifiers are published here. The chart uses a dated snapshot rather than a live counter so that the numbers remain reproducible. When this study is refreshed, the old and new values can be reviewed as a normal content change instead of silently moving between crawls.
Download the aggregate snapshot as JSON or CSV. Both formats contain the same metric names, values, units, denominators, observation window, notes, reuse terms, and limitations shown in this article.
Questions we asked
- Which compression mode did people choose?
- What file size did target-size users ask for?
- How often did settled jobs complete?
- How much data went into and came out of the completed workflow?
- Which format conversions were common?
- Did signed-in users come back for another job?
These are product-usage questions. They are not keyword-volume estimates and they are not a controlled codec benchmark.
Method
We grouped jobs by the compression mode stored when the job was created:
target_size, preset, or resolution. We counted completed and failed jobs as
settled. Jobs still processing remained visible in the outcome chart but were
excluded from the success-rate denominator.
Input and output bytes were summed before conversion to gigabytes and rounding to one decimal place. Target-size statistics use only jobs that actually chose that mode. Repeat use counts signed-in users because anonymous jobs cannot be reliably joined to one person without inventing an identity.
The arithmetic is straightforward:
| Metric | Calculation | Result |
|---|---|---|
| Target-size share | 306 / 424 | 72.2% |
| Preset share | 115 / 424 | 27.1% |
| Settled success | 401 / (401 + 20) | 95.2% |
| Aggregate bytes removed | (80.6 − 22.8) / 80.6 | 71.7% |
| Signed-in repeat users | 28 / 75 | 37.3% |
Result 1: users were solving a size constraint
The strongest signal is not the 20 MB median by itself. It is the combination of 306 target-size jobs and 104 requests between 10 and 20 MB.
That range overlaps common attachment and chat limits. Gmail advertises a 25 MB message limit but base64 encoding makes roughly 18 MB a safer raw-file target. Discord's free cap is 20 MB. WhatsApp has historically behaved like a 16 MB ceiling for ordinary video sharing, even though its current official help text describes connection-dependent limits rather than publishing that number as one universal cap.
The job data does not record “I am sending this through Discord,” so it cannot attribute every 20 MB request to one platform. It can support the narrower conclusion: a large share of users wanted a file near the size ceilings that shape everyday sharing.
What we changed
Landing pages now begin with the exact platform limit or target size, load the compressor already set just below that ceiling, and explain why the preset has headroom. The tool does not make someone translate “balanced quality” into a number through trial and error.
This follows the same principle used on strong tool landing pages: lead with the job, let the visitor run the tool, explain the method, then answer edge cases. The page is not a blog post with a button pushed into the first paragraph.
Result 2: one compression percentage would be misleading
The aggregate source volume fell from 80.6 GB to 22.8 GB. It is tempting to turn that into “videos get 71.7% smaller,” but that sentence would be false as a product promise.
Aggregate reduction mixes different durations, resolutions, codecs, source bitrates, content types, and user settings. A lightly compressed phone video can contain a great deal of removable bitrate. A video downloaded from a social platform may already be near its practical floor. Adding both to one total does not create a prediction for the next upload.
A separate controlled test shows why source type matters. We encoded three 10-second 1080p clips at six CRF values each and scored every output against its source with Netflix's VMAF metric:
| Source at CRF 32 | Output size | VMAF |
|---|---|---|
| Screen recording | 0.79 MB | 89.88 |
| Animation | 1.96 MB | 79.67 |
| Camera footage | 2.43 MB | 74.38 |
Same encoder, same CRF, very different result. The screen recording remained smaller and substantially closer to the source because flat colors and unchanged frames are cheap to describe. Camera motion and sensor noise are not.
The full 18-run experiment, method, and limitations are in CRF explained: what number should you use?.
Result 3: compatibility mattered more than conversion variety
MP4 to MP4 accounted for 357 of 424 jobs. MOV to MP4 was the next largest path at 52 jobs. Only 15 jobs used every other input-output pairing combined.
This is evidence for keeping MP4 with H.264 as the default. It is not evidence that the other 32 supported input containers are unnecessary: rare formats can be the entire reason one person needs a cloud transcoder. It means the default should optimize for the common path while the long tail remains available.
Result 4: completion needs a denominator
The production snapshot contained 401 completed jobs, 20 failed jobs, and three still processing. Saying “401 jobs succeeded” is true but incomplete. The useful rate is 401 of 421 settled jobs, or 95.2%.
We keep processing jobs outside the denominator because they have not produced an outcome. We also do not count refunded credits as completed work. A product metric should describe what happened to the user's file, not what happened to a billing record afterward.
The follow-up experiment
This dataset is observational. It tells us what people chose, not whether one landing-page structure caused more successful compressions. The next question needs an experiment rather than another retrospective chart.
Hypothesis
A landing page that leads with the verified platform limit, presets the exact safe target, and shows the size-versus-duration chart will produce more first completed jobs than a generic “compress video online” page.
Test design
| Element | Control | Variant |
|---|---|---|
| Hero | Generic compressor benefit | Platform limit and safe target |
| Tool default | Balanced preset | Exact target below the ceiling |
| Evidence | Feature claims | Source-dated limit table and bitrate chart |
| Primary metric | First completed job / eligible visitor | Same |
| Guardrails | Failure rate, checkout starts, page speed | Same |
Traffic should be assigned by visitor, not pageview, and remain in one variant for the experiment. The result should be reported with sample sizes and a confidence interval, not only a percentage uplift. We would also segment by landing page after the primary read, but we would not stop the test because one small segment looked exciting.
No result is published yet because the experiment has not been run. A proposed chart is not evidence, and adding a false “23% lift” would make the rest of this study less trustworthy.
Limitations
This is one product. The distribution describes VidSmaller visitors during the observation window, not everyone who compresses video online.
Acquisition shaped the sample. Much of the early traffic came from a sister video-compression site and the 1 GB video compressor. A different channel mix could produce different source files and goals.
Job totals are not unique people. One person can create multiple jobs. The mode chart answers “what did jobs request?” rather than “what percentage of people prefer this mode?”
Volume is aggregate. The 71.7% byte reduction is not an average per file and must not be used as a guarantee.
Destination is inferred only at the market level. A 20 MB target resembles popular platform limits, but the job record does not prove which platform the user had in mind.
Practical takeaways
For someone building or choosing a compressor:
- Put exact target size before codec jargon when a hard upload limit is the likely job.
- Publish the denominator behind every success rate.
- Separate observed production behavior from controlled codec tests.
- Put the source, date, sample size, method, and limitation next to each chart.
- Do not turn an aggregate reduction into a per-file promise.
- Treat a landing-page claim as a hypothesis until a controlled test measures completed jobs, not just clicks.
For someone who only needs a smaller file: use target-size mode when a platform has a hard ceiling, and use a quality preset when there is no exact number to hit. Start from the original each time rather than repeatedly compressing an already compressed result.
FAQ
Is 20 MB the best target size for every video?
No. It was the median target in this dataset because many sharing workflows cluster around that range. Your correct target is the limit you must clear. Use 19 MB for a 20 MB ceiling so normal encoder variation does not push the result over the line.
Does VidSmaller reduce every video by 71.7%?
No. That percentage is the aggregate change from 80.6 GB of input to 22.8 GB of output across different files and settings. Source content and prior compression make individual results vary widely.
Why exclude processing jobs from the success rate?
They do not have a final outcome. Including them as successes or failures would bias the rate. They remain visible in the chart so the snapshot still reconciles to all 424 jobs.
Was this an A/B test?
No. The production-job analysis is observational. The CRF comparison is a controlled encoder experiment, and the proposed landing-page A/B test is a future test whose result has not been claimed.
Can the raw videos be downloaded?
No. Customer videos are private and are deleted under the product's retention rules. This article publishes only aggregate counts. The controlled CRF study uses reproducible public or self-generated reference clips instead.
Compress a video now or start with a verified limit for Discord, email, or WhatsApp.