How to Reduce Video File Size Without Making UI Text Unreadable
The smallest file is easy to produce. Make the video tiny, remove enough frames, and compress it aggressively. The difficult task is keeping the explanation intact.
A product demo has an awkward relationship with video compression. Large flat interface regions are relatively easy to compress, but the information often lives in small labels, thin icons, and brief state changes. Those details can disappear before the overall picture looks obviously damaged. A file can remain attractive enough to approve while becoming less useful as a demonstration.
When you compress a product demo video, the right question is not “How small can this MP4 get?” It is “What is the smallest useful delivery for this placement?” The word useful includes readable text, recognizable results, acceptable motion, reliable playback, and a reasonable waiting cost. You need a controlled comparison to find that point for the actual video.
Decide What Must Survive Compression
Choose the information the viewer needs to see. In a task demonstration, that might be the selected item, the control label, and the saved result. In a pricing explanation, it might be the amount, period, and billing condition. Mark representative timestamps where those details are hardest to preserve.
Include motion in the test. A static paused interface can compress much more cleanly than the same interface moving through a zoom or pan. The codec has to describe changes between frames as well as spatial detail within each frame.
Pick a difficult segment rather than a flattering one. Small text over a gradient, a fast interface movement, or a detailed screenshot can expose problems that a large title card hides. If the video has several distinct visual styles, choose a short segment from each.
Define the destination size before judging. A label that is readable in a full-screen desktop player may be useless in a 390-pixel feed. Conversely, microscopic defects visible at 400 percent zoom may have no practical effect at the intended size. Inspect native pixels for diagnosis and real display size for acceptance.
Keep a high-quality reference. Ideally this is a lossless or visually strong master, not a previously compressed file downloaded from a platform. Repeatedly recompressing an already damaged rendition makes it harder to distinguish new damage from inherited artifacts.
Change One Variable at a Time
Resolution, frame rate, codec, quality setting, audio bitrate, and duration all affect size. Changing several together can produce a smaller file without telling you which tradeoff caused the visible damage.
Start by preserving the composition dimensions and frame rate. Compare a few quality levels using the same encoder and source. If the result is still too large, test a dimension change separately. If the video contains little meaningful motion, investigate frame-rate changes as another separate decision.
Do not assume that reducing frame rate is free because the clip mostly shows an interface. A moving cursor, scrolling list, or camera zoom can become visibly less continuous. If you reduce frame rate, inspect those actions at normal playback speed rather than only comparing extracted frames.
Likewise, do not shrink a full interface to save bytes before checking whether the shot itself needs redesign. A tighter view of the relevant task may produce a more readable video and a simpler image to encode. That is an editorial improvement with a compression benefit, rather than an encoder trick.
Record the settings for each candidate in its filename or an accompanying note. A folder containing test1.mp4, test2.mp4, and better.mp4 becomes difficult to interpret after a few iterations. The comparison only helps if you can reproduce the candidate you prefer.
Understand What a Quality Control Actually Controls
A quality-based encoder setting lets the encoder vary the amount of data used according to the content. For libx264, CRF is one such control: lower values generally target higher quality and larger files, while higher values accept more loss. The resulting bitrate depends on the material.
A target bitrate answers a different question: how much data should the encoder use over time? That can be useful when a delivery system imposes bandwidth constraints. It does not guarantee equal quality across simple and complex scenes.
FFmpeg’s codec documentation describes the libx264 wrapper and its available controls. Use the documentation for the actual encoder in your build rather than assuming similarly named quality values have identical meanings across hardware and software encoders. FFmpeg codec documentation
A slower encoder preset generally spends more computation searching for an efficient representation. It is not the same control as resolution or perceptual quality, and “slower” does not mean a video plays more slowly. Avoid combining a preset change with several other changes if you want to understand its effect.
Also distinguish the container from the codec. MP4 is a container; the video and audio streams inside it have their own encodings. A smaller MP4 created with a different codec may have different compatibility requirements. File extension alone is not a delivery specification. MDN video codec guide
A Small, Reproducible Encoding Study
For this article, a real screenshot of Remotion’s rendering documentation was used to create a six-second panning study. The study was 1280 by 720 at 30 frames per second, with no audio. A lossless FFV1 intermediate was encoded with FFmpeg 8.1 using libx264, the medium preset, and the same pixel format at three CRF values.
The files measured 133,499 bytes at CRF 18, 87,536 bytes at CRF 28, and 52,168 bytes at CRF 38.
The two images come from the same timestamp and crop. At the stronger compression level, thin letter edges and small text show visible damage. The broad layout remains recognizable. That is exactly why checking only whether the video “still looks fine” is insufficient for a UI demonstration.
You can repeat the same pattern with your own difficult segment. Save the reference, preserve the settings, extract matching frames, and watch the candidates in motion. A visual comparison should supplement measured size, not be replaced by it.
Inspect More Than the Headline
Compare small text, thin lines, gradients, and moving boundaries. Large type often survives compression well because its shapes occupy many pixels. A small field label can lose a meaningful distinction while the headline remains pristine.
Check whether the viewer can identify the result of the demonstrated action. For example, a status chip changing from “Draft” to “Ready” must remain legible after encoding. If the chip’s text becomes mushy, the video no longer proves the outcome even if the cursor movement looks smooth.
Watch the segment at normal speed. Some compression artifacts are more apparent in motion: edges shimmer, blocks appear briefly, or small details change unpredictably between frames. A single extracted image can miss those temporal defects.
Then inspect a few decoded frames at native resolution to understand the cause. Do not make the approval decision from an enlarged crop alone. Magnification is useful for identifying artifacts, while the actual destination size tells you whether those artifacts interfere with the task.
If you use a numerical image-quality metric, treat it as supporting evidence. An average score can be dominated by large unimportant regions while a tiny critical label fails. A human-readable task criterion remains necessary: can the viewer read the condition, follow the action, and recognize the result?
The CRF 38 file is 81,331 bytes smaller, a reduction of about 61% from CRF 18 in this clip. That saving is visible in the file record; the cost is visible in the text crop. The practical choice depends on whether the affected detail carries the demonstration. A damaged decorative label may be tolerable. A damaged result status or billing condition removes information the viewer needs. Compare those regions before accepting the saving, rather than judging from the headline and flat background alone.
Reduce Video File Size Before Sacrificing UI Detail
Duration is an overlooked source of file size. A long empty opening or redundant ending consumes data without adding explanation. Removing repetition can improve the video and reduce its size simultaneously. Do not cut the shared reading hold that makes a price statement understandable merely because it is easy to trim.
Audio can also be unnecessary for some placements. If the video is genuinely silent by design, an unused audio stream may be removable. If narration carries meaning, lowering or removing audio is a content change, not a harmless optimization. Verify the intended listening experience.
Check whether you are delivering excessive dimensions for the placement. A small decorative loop may not need a huge master as its only web asset. A detailed product tutorial may need a larger rendition or multiple responsive options. The right choice depends on what viewers need to read, not on a universal rule that bigger or smaller is always better.
Avoid unnecessary noise, grain, and constantly moving detailed backgrounds behind UI. These effects can consume encoding complexity while making text harder to read. Their artistic value may justify the cost, but the tradeoff should be deliberate. A calmer background can improve both readability and compression.
Do not repeatedly export from a compressed candidate. Return to the master when changing settings. Generational loss can accumulate, and a later higher bitrate cannot restore detail discarded in an earlier transcode. Keep the clean source available throughout the comparison.
Prepare the File for Its Delivery Path
A file can be visually acceptable and still start slowly because of its container layout or hosting behavior. For ordinary MP4 delivery, placing playback metadata near the beginning can improve startup conditions; FFmpeg’s +faststart option is commonly used for that purpose. It rearranges metadata rather than improving text quality.
Keep that distinction clear. A faster-starting file is not necessarily smaller, and a smaller file is not necessarily more compatible. Optimize the relevant problem instead of treating every export option as part of one vague quality preset.
If a platform will transcode the upload, inspect the processed result. The candidate that looks best locally may not be the rendition the audience receives. Preserve a strong upload source and evaluate the platform’s actual output at the intended placement.
For a website, check that the server delivers the expected asset, that the player displays it at a sensible size, and that seeking works where required. Compression does not fix a broken URL, an incorrect content type, or a layout that enlarges the video beyond useful detail.
Record the accepted delivery separately from the master. A high-quality archive copy and an efficient web copy serve different purposes. Keep their relationship clear so a future editor does not use the compressed web rendition as the only source for another campaign.
Interpret Size Savings in the Context of the Page
A smaller video does not automatically make the whole page meaningfully faster. The page may defer the download, use a small poster before interaction, or spend most of its loading budget elsewhere. Measure the actual delivery path before treating every saved byte as an equivalent user benefit.
For a video that starts immediately above the fold, startup behavior and initial transfer matter. For an optional tutorial near the bottom of a page, a clear poster and sensible loading behavior may protect the initial experience while preserving a stronger video rendition. These are placement decisions, not competing moral rules about file size.
Also consider repeated use. A shared video asset may be cached across pages, while several separately named copies may require separate downloads. An asset strategy can sometimes remove more unnecessary transfer than another aggressive encoding pass. Verify the actual requests before claiming that a change improved loading.
Do not use this reasoning to ignore an obviously excessive file. It helps choose the next useful action. If reducing quality damages essential text for a tiny marginal saving, inspect duration, source selection, loading behavior, and duplicated assets before accepting the damage.
Keep the master separate from the web delivery so you can revisit the tradeoff later. A new destination may need a different size or quality level. Starting from a clean master gives you options; starting from the smallest previous upload compounds earlier losses.
The decision should connect the measured saving to a real viewing condition. “This smaller rendition remains readable in the page’s player” is stronger than “We reduced the file by a large percentage” when that percentage comes from removing detail the viewer needed.
Set an Acceptance Threshold You Can Explain
The final choice should be defensible in ordinary language. “This candidate is smaller, and the selected control, result label, and pricing condition remain readable at the published width” is a meaningful decision. “CRF 28 is best” is not a transferable conclusion without the source and viewing conditions.
If two candidates are visually indistinguishable for the task, the smaller one may be preferable. If the smaller candidate damages a critical label, choose the larger one or redesign the shot. The point of compression is efficient communication, not winning a file-size contest.
Keep the evidence lightweight: source identity, settings, measured size, representative frames, and the destination checked. This makes future revisions faster because the next editor can start from an established comparison instead of guessing what “optimized” meant.
A useful compressed product demo is one that arrives efficiently and still demonstrates the product. Protecting that second half requires looking closely at the small details where the explanation actually lives.