How to Compress Screen Recordings Without Losing Quality

Why screen recordings are so large by default

A ten-minute screen recording captured at 1080p can easily hit 500 MB to 2 GB depending on the tool and settings used. That’s often five to ten times larger than a comparable recording of live-action video. The reason is codec choice.

Most screen recorders default to a lossless or near-lossless codec — or to a lossy codec with a very high bitrate — because that preserves every pixel of the UI exactly. This matters while recording (you don’t want artefacts on text and sharp-edged icons), but it produces files far larger than what sharing platforms or email attachments require.

Compression brings the size down to something shareable without a visible quality drop — because the right codec settings exploit the fact that most screen content is already highly compressible: flat backgrounds, repeated elements, and large areas of identical colour.

The two levers: codec and bitrate

Video compression is controlled by two main variables:

Codec — the algorithm that encodes video frames. For screen recordings, the codecs that matter are:

• H.264 (AVC) — the most compatible choice. Plays on every device, every browser, and every major platform without any conversion step. For most screen recording purposes, H.264 at a reasonable bitrate is the right default.
• H.265 (HEVC) — roughly 40% smaller than H.264 at the same visual quality. Widely supported on modern hardware but not universally playable in browsers without a codec licence. Good for storage, not ideal for direct web upload.
• VP9 — Google’s royalty-free alternative to H.265. Supported in Chrome, Firefox, and Edge. Slightly better compression than H.264 with better browser compatibility than H.265.
• AV1 — the newest open codec, with the best compression-to-quality ratio of the four. Support is still maturing; encode times are much slower than the others.

For a screen recording you’re going to email or upload to Slack, Loom, Google Drive, or YouTube: H.264. For a recording you’re storing locally and want to keep small: H.265 or VP9.

Bitrate — the amount of data used per second of video, measured in kilobits (kbps) or megabits (Mbps). A higher bitrate means better quality but larger files.

For a 1080p screen recording of mostly static content (slides, documents, dashboards), a bitrate of 2–4 Mbps H.264 produces near-lossless visual quality at a fraction of the raw file size. For recordings with frequent motion (scrolling, animations, live coding), 4–8 Mbps is more appropriate.

By comparison, raw screen capture tools often record at 20–100 Mbps or more. Going from 50 Mbps to 4 Mbps with an appropriate codec is a 90%+ file size reduction with no visible quality difference in the final output.

Resolution and frame rate

Bitrate and codec matter most, but resolution and frame rate also affect file size:

Resolution. If your recording was captured at your display’s native 4K or 1440p resolution but the audience will watch it on a 1080p screen, exporting at 1080p eliminates the extra pixels with no perceptible loss. For software tutorials viewed on typical laptop screens, 720p is often sufficient.

Frame rate. Screen recordings of mostly static content (document walkthroughs, slides, configuration steps) don’t need 60 fps. 24 or 30 fps is indistinguishable from 60 fps for those use cases and significantly reduces file size. Keep 60 fps only if the recording includes smooth animations or fast cursor movement where the higher frame rate is visible.

How to compress in practice

Screenkit exports recordings in a format optimised for direct sharing, but if you need to further compress a file you already have, the fastest approaches are:

In-browser tools. Upload the file to a browser-based video compressor. These use ffmpeg.wasm to run the encode client-side — no upload to a third-party server. Set the output to H.264 and a target bitrate of 3–5 Mbps for 1080p content.

HandBrake (free, cross-platform). Open the file, choose the H.264 codec, set the quality slider to RF 22–26 (higher number = more compression, lower visual quality), and export. RF 23 is a widely used default that produces excellent quality at small file sizes for screen content.

ffmpeg (command line). The most flexible option:

ffmpeg -i input.mp4 -vcodec libx264 -crf 23 -preset slow output.mp4

Adjust crf (Constant Rate Factor) between 18 (near-lossless) and 28 (smaller file, more artefacts). For screen recordings, 22–24 is usually the sweet spot.

What not to compress too aggressively

The compression advice above works well for most content, but a few cases need care:

Text-heavy recordings. H.264’s block-based compression can produce ringing artefacts around sharp text edges if the bitrate is set too low. If your recording shows code, terminal output, or dense spreadsheets, stay closer to 5–8 Mbps rather than 2–3 Mbps.

Recordings intended for re-editing. If you’ll use this recording as source footage for further editing, keep a high-quality original. Compress only the final export.

Legal or compliance recordings. Some contexts require you to preserve the original, unmodified recording. Check whether a compressed version is acceptable before discarding the source.

Quick reference: target settings by use case

Use case	Resolution	Frame rate	Codec	Bitrate
Slack / email attachment	720p	30 fps	H.264	2–3 Mbps
YouTube / Loom upload	1080p	30 fps	H.264	4–6 Mbps
Local archive	1080p	30 fps	H.265	2–4 Mbps
High-motion content	1080p	60 fps	H.264	6–10 Mbps
Slides / document walkthrough	720p	24 fps	H.264	1–2 Mbps

These are starting points. The right balance depends on your specific content and the platform you’re sharing to — most platforms re-encode uploads anyway, so uploading a reasonably compressed H.264 file is often better than uploading an enormous raw file and letting the platform do a single aggressive pass.