A short screen recording can explain a bug better than several paragraphs. It can also become the largest attachment in the issue.
That creates a familiar problem: reduce the file enough to share it, but keep the terminal output, error message, and cursor movement useful to the person watching.
For developer recordings, “looks fine” is a specific requirement. Someone needs to read the line that failed, see which button was clicked, or follow a layout shift. A smaller video that hides those details creates another round of questions.
Here is a practical way to approach the tradeoff.
1. Start with bitrate, not the file extension
An .mp4 extension does not tell you how large a recording should be. MP4 is a container; the encoded video and audio inside it determine much of the file's size and playback behavior. MDN explains this distinction in its guide to media containers.
For estimating size, a useful relationship is:
File size in MB ≈ duration in seconds × total bitrate in Mbps ÷ 8
“Total bitrate” includes both video and audio. This estimate uses decimal megabytes and leaves out container overhead.
For a hypothetical 60-second recording:
| Average total bitrate | Approximate size |
|---|---|
| 12 Mbps | 90 MB |
| 6 Mbps | 45 MB |
| 3 Mbps | 22.5 MB |
These are arithmetic examples, not compression benchmarks or recommended settings. The bitrate needed for a readable result depends on the recording and encoder.
The useful takeaway is that a short duration does not guarantee a small file. A recorder can produce a large clip simply by encoding a lot of data per second.
2. Decide what the viewer must be able to read
Before changing settings, identify the detail that makes the recording useful.
For a bug report, that might be an error message. For a product demo, it might be a menu label. For an animation issue, the movement itself may matter more than small text.
This gives you a concrete quality check:
Can someone understand the problem at the size where they will actually watch the video?
Pause the result on the smallest important text. Then play the section with scrolling, transitions, or rapid cursor movement. A readable still frame does not tell you everything about the moving video.
3. Treat resolution as a separate decision
Lowering resolution can help reduce file size, but it can also remove the detail your viewer needs.
A full desktop recording with several windows may contain tiny text before compression even starts. Reducing that entire desktop to a smaller frame makes the text smaller again.
For a text-heavy recording, try a quality adjustment while keeping the original resolution first. If the output remains too large, test a lower resolution and check the important text again.
When making a new recording, capture the relevant window or region and increase the editor or terminal font size beforehand. That gives you a more useful source to work with. An encoder cannot recover legibility that was missing in the original capture.
4. Expect a tradeoff, not a fixed percentage
Two recordings with the same duration and dimensions can compress differently. A mostly static settings panel and a page full of scrolling content give the encoder different material to work with.
Lossy compression can introduce artifacts, particularly when settings become aggressive. MDN's video codec guide covers the factors that affect encoded video and the artifacts to watch for.
This is why I would avoid choosing a setting solely because it produces an impressive reduction percentage. The useful output is the one that fits the sharing constraint and still communicates the issue.
If the source is already efficiently compressed, another pass may offer little benefit. Keep the original and compare the actual results.
5. A browser-based workflow for an existing recording
Disclosure: I'm building CompressFly. Its browser-based video compressor provides a straightforward way to try quality and resolution changes on a recording you already have.
The workflow is:
- Select one video from your device.
- Choose a quality level and either keep the original resolution or select a lower output resolution.
- Run compression, compare the original and output file sizes, and download the result.
The video is processed locally in your browser rather than uploaded to a processing server. The site still needs to load its application resources; local processing does not imply that the entire website works offline.
It also means the work uses your device's resources. Allow time for processing, especially with longer or higher-resolution recordings.
6. Check the downloaded file before attaching it
My final check would be short:
- Open the downloaded video and confirm that it plays.
- Read the smallest text needed to understand the issue.
- Watch the section where the bug occurs, including any relevant motion.
- Check narration and audio timing if the recording includes sound.
- Confirm the actual file size fits the destination's current upload limit.
Keep the source recording until the shared copy has been checked. If a reviewer needs a closer look, having the original is much more useful than trying to compress an already degraded export again.
A bug recording has a job: help another developer see what happened. File size matters because it makes that evidence easier to share. Readability matters because it makes the evidence useful.
Top comments (0)