Choose Small when you want the Video Compressor to cap output width at 640 pixels and target 24 frames per second, regardless of the source resolution. The preset is one of three explicit product choices — Small, Balanced, and Quality — and each one applies a bounded width, frame rate, and bits-per-pixel heuristic to the same local re-encode into a WebM file. Picking Small is a deliberate decision to prioritize a smaller file over sharper detail or smoother motion, and it fits clips where reduced resolution and a lower frame rate are acceptable trade-offs. The preset preserves the source aspect ratio, never enlarges the source, rounds output dimensions down to even pixel values, and clamps the requested bitrate between 180 kbps and 8 Mbps. Choosing Small therefore means accepting a 640 px-wide output and a 24 fps stream in exchange for the leanest preset the tool exposes.
What the Small Preset Actually Limits
The Small preset applies three concrete caps to the re-encode: a maximum output width of 640 pixels, a target frame rate of 24 fps, and a bits-per-pixel budget that the Video Compressor converts into a requested bitrate. That bitrate is then clamped to a floor of 180 kbps and a ceiling of 8 Mbps before the browser's MediaRecorder begins writing the WebM file. The preset never enlarges the source, preserves the source aspect ratio, and rounds each output dimension down to an even number so the chosen codec accepts the frame without complaint. Audio is captured and included in the WebM only when the browser exposes a track through HTMLMediaElement captureStream, and only the picture is downscaled — the preset does not alter volume, mix tracks, or strip metadata beyond what the WebM container itself drops. Everything Small does happens in the current tab; the page draws the playing video into a bounded Canvas and records that canvas stream in real time, so a two-minute source takes roughly two minutes rather than finishing instantly.
How Small Compares to Balanced and Quality
The three presets differ only in width, frame rate, and the bits-per-pixel target used to derive the requested bitrate. Balanced caps width at 1280 pixels and targets 30 fps. Quality caps width at 1920 pixels and also targets 30 fps. Small sits below both and pairs its lower resolution with the lower 24 fps cadence. Use the table below to see the exact published values side by side.
| Preset | Max output width | Target frame rate | Aspect ratio | Bitrate range |
|---|---|---|---|---|
| Small | 640 px | 24 fps | Preserved, never enlarged | 180 kbps – 8 Mbps |
| Balanced | 1280 px | 30 fps | Preserved, never enlarged | 180 kbps – 8 Mbps |
| Quality | 1920 px | 30 fps | Preserved, never enlarged | 180 kbps – 8 Mbps |
All three presets share the same processing pipeline: local decode, Canvas drawing, MediaRecorder capture, and a final Matroska Duration fix-up so the downloaded WebM reports a finite duration to players. The only preset-driven changes are the values in the table above.
When Small Is the Right Choice
Small is the preset to reach for when the destination cares about bytes more than pixels. Concrete situations where it fits include sending a quick clip in a chat or email attachment, attaching a preview alongside a written message, embedding a short motion sample on a page where bandwidth matters, building a thumbnail-sized animated preview from a longer source, or reducing a low-motion screen recording before archiving it. A clean 2D animation, a software demo with limited motion, a static talking-head clip, or a screen capture with predictable frames all benefit from the lower resolution and reduced frame rate because the encoder has less new information to describe in each frame. In each of these cases the trade-off is favorable: a noticeably smaller file with picture quality that still communicates what is on screen.
When Small Will Not Save You Anything
Compression is content-dependent, and the same preset that shrinks a clean animation can produce a file the same size or larger than the source on harder material. Sources that already use an efficient codec, sources with heavy grain, sources with constant camera shake, sources full of rapid detail changes, and sources with high-frequency noise all leave the encoder with little redundancy to remove. In those cases the requested bitrate is forced high by the bits-per-pixel heuristic, the codec still has to describe every frame's motion, and the resulting WebM can match or exceed the original byte count. The Video Compressor reports the actual signed byte change after the encode finishes, so a positive number — meaning the output is larger — is a signal that Small was the wrong preset for that particular source. Try another preset, or try a different source.
How to Pick Small in the Video Compressor
The Video Compressor is a browser-based re-encoder that runs entirely in the current tab, so picking Small is a matter of choosing the right file, selecting the Small preset before starting, and waiting for the source to play through at real time. Follow the steps below.
- Open the Video Compressor in a current desktop browser that supports MediaRecorder and Canvas capture.
- Click the file picker and choose a browser-decodable source no larger than 500 MiB, no longer than five minutes, no wider or taller than 4096 pixels on either side, and no larger than 3840 × 2160 pixels of decoded area.
- Select the Small preset from the preset options. The selected preset controls the maximum width, frame rate, and bits-per-pixel target used for the encode.
- Start the compression and keep the tab open. The source plays in real time on the page while the encoder records each frame into the WebM output — a two-minute source therefore takes roughly two minutes rather than completing instantly.
- Watch the reported progress, which tracks the source's playback time. Closing the tab, navigating away, switching files, or changing preset mid-encode invalidates the active job and releases temporary Object URLs.
- When the encode finishes, review the output dimensions, the input and output bytes, and the measured percentage change that the page displays. The percentage is calculated only from the two actual Blob sizes, and a positive value means the output is larger than the source.
- Download the WebM and play it fully — picture and sound, beginning to end — before deleting the original source. Confirm that size, duration, picture, and audio meet the destination's requirements.
If the result is not what you expected, repeat the steps above with a different preset. For a description of the broader local pipeline that the presets share, see the explanation of how the local re-encode works.
How to Verify the Saved Bytes
The Video Compressor does not promise that any preset always produces a smaller file, so the only honest check is the actual byte change that the tool reports at the end of an encode. Read that number as a signed percentage: negative means the WebM is smaller, positive means it is larger. Open the downloaded file in a player that can show its container properties and confirm the duration, dimensions, and that the file is not silently truncated. Play the entire clip, including any audio the browser managed to capture, and watch for missing frames, out-of-sync sound, or stutter near the end. The tool inserts a Matroska Duration value in timestamp-scale ticks so playback reports a finite duration, but verifying end-to-end is still on you. For a closer look at what the page actually measures and reports, the accuracy guide walks through the reported values and how they are computed.
Limits and Trade-offs Worth Knowing
A few hard limits bound what the Small preset can do inside the Video Compressor. The input cap of 500 MiB, 300 seconds, 4096 pixels per side, and 3840 × 2160 pixels of decoded area applies to every preset, including Small. The output container is always WebM — the tool tries VP9, then VP8, then generic WebM according to the browser's reported codec support, which means two browsers can produce different byte counts for the same source and the same preset. Audio is captured only when the browser exposes a track; subtitles, chapters, attachments, rotation tags, color metadata, and HDR signaling are not preserved, and the encoder does not normalize volume or mix tracks. For archival masters, professional delivery specifications, deterministic cross-platform output, exact codec profiles, two-pass rate control, fixed keyframe intervals, or subtitle preservation, use a maintained desktop encoder such as FFmpeg with a reviewed command. The MediaRecorder and Canvas captureStream behaviors behind these limits are documented at MDN's MediaRecorder page and MDN's HTMLCanvasElement.captureStream() page.
None of the source bytes, decoded frames, or output bytes leave the current tab, and nothing is uploaded. Lizely receives no video, thumbnail, duration, file name, codec, or result. Keep the original source on disk until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements.