{{ summaryTitle }}

{{ summaryValue }}

{{ summaryLine }}

Goal{{ params.target_size_percent }}% Resolution{{ resolutionLabel }} PrivacyLocal only

{{ summaryAnnouncement }}

Video compression inputs
{{ sourceFile ? sourceFile.name : 'Drop a video here or browse' }}
{{ sourceFile ? sourceDetails : 'MP4, MOV, WebM, or MKV that this browser can decode' }}
{{ sourceReading ? 'Reading video metadata…' : sourceDropStatus }}
Maximum 80 MB, 5 minutes, and 1920 × 1080 pixels.
Lower targets save more space but remove more picture detail.
Preserve keeps the source size; capped options reduce only larger videos.
96 kbit/s is a compact general-purpose default.
Encoding runs on this device and may take longer than the video duration.
{{ encodingProgress }}%
The neutral default is Preserve. Use a cap only when smaller motion sampling is acceptable.

Compression plan

{{ row.label }}{{ row.display }}

Compressed video

{{ chartExportStatus }}

The chart renderer is unavailable. The same values remain in the compression plan and encoding ledger.

{{ ledgerExportStatus }}
SignalValueMeaningCopy
{{ row.label }}{{ row.display }}{{ row.detail }}

Introduction:

A video that plays well on a phone can still be too large for a form, message, learning platform, or content library. The useful goal is rarely “make it as small as possible.” It is to fit the delivery limit while keeping enough picture detail, motion, and sound for the way the video will be watched.

Video size is mainly a product of duration and bitrate. Bitrate is the amount of data spent per second, shared between the moving picture and any audio track. A shorter clip can use more bits per second than a long clip at the same final size, so two videos with similar dimensions can compress very differently.

Video compression choices and their practical effects
Choice What it changes Most visible risk
Smaller byte target Leaves fewer bits for every second of video Blockiness, smearing, or lost fine detail
Lower resolution Reduces the number of pixels that must be encoded Soft text, faces, or screen recordings when viewed large
Lower frame rate Stores fewer motion samples each second Jerky pans, sports, cursor movement, or animation
Lower audio bitrate or mute Returns more of the byte budget to the picture Thin music, rough speech, or missing sound

Resolution and bitrate solve different problems. Downscaling helps when the source has more pixels than the destination can display. Lowering bitrate makes each remaining pixel cheaper to store. A 1080p talking-head clip may tolerate a lower bitrate, while fast movement, confetti, foliage, film grain, and detailed screen captures usually need more data to avoid visible artifacts.

A target percentage is a planning constraint, not a promise of exact bytes. Encoders divide data unevenly according to scene complexity, and containers add overhead. The finished file may land above or below the estimate, which is why measured output size and playback matter more than the pre-encode plan.

Keep the source as the master copy. Compression is normally lossy, so encoding an already compressed result again can accumulate damage even when each individual change looks modest.

How to Use This Tool:

Start with the destination limit, then spend the available bytes on picture, sound, and motion in that order of importance.

  1. Choose one Source video. It must be no larger than 80 MB, no longer than 5 minutes, and no larger than 1920 × 1080 or 1080 × 1920 pixels.
  2. Select a Target file size. The balanced 60% option is a sensible first run; 35% asks for much stronger compression, while 75% keeps more data.
  3. Set Maximum resolution only when the destination does not need the source dimensions. Capped choices preserve aspect ratio, use even pixel dimensions, and never enlarge a smaller source.
  4. Choose an Audio bitrate. Speech can often use 64 kbit/s, 96 kbit/s is the general default, and muting leaves the whole payload budget for video.
  5. Leave Frame-rate cap at Preserve unless fewer motion samples are acceptable, then start compression. If the size goal leaves less than 100 kbit/s for video, choose a larger target, mute audio, or shorten the source.

Interpreting Results:

Compare Verified output with Source size, then play the compressed MP4. Measured saving tells you what happened to the bytes; it does not tell you whether faces, captions, gradients, or fast movement still look acceptable.

  • A note that the result is above the goal means the output exceeded the requested percentage by more than 5%. It is still smaller than the source, but it did not meet the planned size closely enough.
  • Output geometry should match the intended display size and aspect ratio. Black padding may appear where the fitted picture does not fill the even output dimensions exactly.
  • A verified video-only fallback means local encoding succeeded without audio and at a reduced motion cadence. Do not use that result when the soundtrack or smooth movement is essential.

Watch a beginning, a busy middle scene, and the end. That catches playback failure, visible compression damage, audio mismatch, and truncated duration more reliably than file size alone.

Technical Details:

The output is an MP4 containing H.264 video and, when retained, AAC audio. The requested byte share becomes a payload budget over the measured duration. Audio is reserved first; the remainder becomes the planned video bitrate. A 3% allowance leaves room for container overhead.

Formula Core

Let B be source bytes, p the selected target percentage, t duration in seconds, and a the chosen audio bitrate in kbit/s. The byte target and total payload budget are:

Btarget = Bp100 rpayload = 8Btarget1000t × 0.97

Video bitrate is the payload budget minus audio, rounded down to a 10 kbit/s step and capped at 8000 kbit/s. A plan below 100 kbit/s is rejected.

rvideo = min ( 8000 , 10 rpayload-a10 ) Bestimate = t(rvideo+a)10008×0.97

For a 12,000,000-byte, 60-second source at a 60% target with 96 kbit/s audio, the payload budget is 931 kbit/s. Video receives 830 kbit/s after subtraction and 10 kbit/s rounding, producing an estimated 7,159,794 bytes, about 6.8 MB as displayed, before the real encode is measured.

Transformation Core

Video compression transformation and verification stages
Stage Rule Verification
Geometry Scale the longest side down only when it exceeds the chosen cap; round width and height down to even pixels. Decoded output dimensions must equal the plan.
Encode Write H.264 video, optional AAC audio, and an optional 24 or 30 fps ceiling. The result must reopen as an MP4 with a playable video track.
Duration Preserve the source timeline. Difference must be no more than 0.15 seconds or 5% of source duration, whichever is larger.
Size Measure the generated bytes rather than trusting the estimate. The output must be smaller than the source; otherwise conversion stops.
Local fallback If the primary path is unavailable, sample frames at 12 fps and create video-only H.264. Dimensions and duration still pass the same checks; the result is identified as video-only.

The estimate can differ from the finished file because actual frame complexity and rate control affect how many bytes are written. Measured size, decoded tracks, dimensions, duration, and playback are the final evidence.

Privacy Notes:

The selected video is read and encoded in the browser. It is not uploaded to a video-conversion service, and the output remains in page memory until you download it or leave the page.

  • Supporting code must load before local encoding can begin, so an internet connection may be needed on first use.
  • Source metadata is not copied into the MP4 output. Keep the original if timestamps or camera metadata matter.
  • Close the tab after working with sensitive footage, and review the downloaded file before sharing it.