A three minute clip off a modern phone can easily run past 800 megabytes. It will not fit in an email, it will crawl through an upload form, and it will sit on a drive taking up space out of all proportion to what it actually contains. The instinct is to run it through the first tool that promises a smaller file, accept whatever comes out, and discover a week later that the footage now looks like it was filmed through a window in the rain.
It does not have to work that way. Video compression is not a single slider trading size against quality. It is four or five independent decisions, and most of the file size in a typical video is being spent on things the viewer will never perceive: pixels beyond the size of the screen it will play on, frames beyond what the motion requires, uncompressed audio, and footage nobody will watch. Strip those out properly and a file can lose seventy percent of its weight while looking effectively identical.
This guide covers what actually consumes space in a video file, how bitrate and CRF really work, the four levers that control size, the settings that hit each platform's limits, and the specific mistakes that turn a reasonable compression job into a visibly damaged one.

What this guide covers
What Actually Makes a Video File Large
Before changing any setting it helps to know where the megabytes are going, because the answer is rarely what people assume. File size in video is the product of a small number of factors multiplied together, and multiplication is unforgiving: two settings each twice as expensive as they need to be produce a file four times larger than necessary.

The arithmetic behind file size
The relationship is almost embarrassingly simple. File size equals bitrate multiplied by duration. A video encoded at 8 megabits per second running for 60 seconds contains 480 megabits, which is 60 megabytes. Everything else, resolution, frame rate, codec choice, scene complexity, feeds into that single bitrate number by determining how many bits the encoder needs in order to hit a given quality.
Which means there are exactly two ways to make a file smaller: reduce the bitrate, or reduce the duration. Every technique in this article is ultimately one of those two things wearing a different hat.
Why raw video is impossible and compression is mandatory
A single uncompressed 1080p frame holds about 6.2 megabytes of pixel data. At 30 frames per second that is 186 megabytes for every second of footage, roughly 11 gigabytes per minute. No consumer device stores video that way, and no network could carry it.
What makes compression possible is redundancy. Consecutive frames in real footage are overwhelmingly similar. If a person speaks into a static camera, the background is byte for byte identical across hundreds of frames. Video codecs exploit that by storing a complete reference frame occasionally, then storing only the differences for everything in between. On top of that they discard fine detail within frames that human vision is poor at resolving, particularly in color information, which the eye samples at far lower resolution than brightness.
The practical consequence is that content determines compressibility. A locked off interview compresses beautifully because almost nothing changes between frames. Handheld footage of leaves moving in wind, confetti, water, or fire compresses terribly because nearly every pixel changes every frame and there is no redundancy to exploit. This is why identical settings produce a 40 megabyte file from one clip and a 300 megabyte file from another of the same length.
Where the space is usually being wasted
In practice, most oversized video files are oversized for one of five reasons, and all five are correctable.
- Resolution far beyond the display size. A 4K file destined for a 700 pixel wide embed carries roughly thirty times more pixels than anyone will see.
- High frame rate on content that does not need it. A 60 frames per second screen recording of a slide deck is spending double the data of a 30 frames per second version for no perceptible benefit.
- Uncompressed or overspecified audio. PCM audio in a camera original can add ten megabytes per minute. Encoded to AAC at 128 kbps it becomes under one megabyte per minute.
- Footage that should have been cut. The lens cap at the start, the walk back to the camera at the end, the forty seconds of dead air in the middle.
- A default bitrate far above the quality ceiling. Many cameras and exporters use conservative, very high bitrates so that no footage is ever damaged, which means most footage is far larger than it needs to be.
The core principle
- File size equals bitrate multiplied by duration. Nothing else.
- Resolution, frame rate, codec, and content complexity all act by changing the bitrate needed for a given quality.
- Data you delete costs nothing. Data you compress still costs something.
- Cut and downscale first, then adjust quality. Never the reverse.
Bitrate and CRF: The Real Quality Dial
If you understand only one technical concept from this article, make it this one. Bitrate and its smarter cousin CRF are where quality is actually decided, and almost every bad compression result comes from setting them wrong.

What bitrate actually buys you
Bitrate is the data budget per second of video. Give the encoder more and it can preserve more detail, gradients stay smooth, edges stay sharp, and fast motion stays clean. Starve it and it starts making visible compromises: blocks appear in areas of flat color, fine texture turns to mush, and moving objects smear.
What surprises people is that the relationship is not linear, it is a curve with a sharp knee. Going from 2 to 4 megabits per second on a 1080p clip produces a dramatic, obvious improvement. Going from 8 to 16 produces a difference most viewers cannot detect at all in normal playback. The goal of good compression is finding that knee: the point where additional bits stop buying visible quality.
The position of the knee depends on content. Static presentations reach it at 2 or 3 megabits per second. Talking heads reach it around 5. General footage with camera movement reaches it around 8. Fast action, sports, or anything with water, foliage, or particles pushes it to 12 or higher. This is why a single recommended bitrate never works for everything.
Constant bitrate vs variable bitrate
Constant bitrate spends exactly the same number of bits every second regardless of what is happening on screen. It produces predictable file sizes and predictable streaming behaviour, which is why broadcast uses it, but it is wasteful in the extreme for ordinary content. A static title card gets the same generous budget as an explosion, so one is overspent and the other is starved.
Variable bitrate lets the encoder move the budget around, spending heavily on complex moments and almost nothing on simple ones while hitting a target average. For essentially every use outside live broadcast, variable bitrate produces better quality at the same file size, and it should be your default.
CRF, the setting that thinks for you
Constant Rate Factor turns the problem inside out. Instead of specifying a file size and hoping the quality lands somewhere acceptable, you specify a quality level and let the encoder spend whatever each scene needs to reach it. Simple scenes come out small, complex scenes come out large, and the perceived quality stays constant throughout.
For H.264 the CRF scale runs from 0 to 51, and lower numbers mean higher quality. The practical range is narrow:
| CRF value | What it looks like | Relative size | Use for |
|---|---|---|---|
| 17 to 18 | Visually lossless, no detectable difference | Large | Masters and archives |
| 20 to 21 | Excellent, safe for critical work | Moderate | Client delivery, portfolio |
| 23 | The default, very good for almost everything | Balanced | General use, uploads |
| 26 to 28 | Noticeable softening in motion | Small | Email, tight size limits |
| 30 and above | Obvious blocking and smearing | Very small | Avoid unless desperate |
A useful rule of thumb: raising CRF by 6 roughly halves the file size. Dropping it by 6 roughly doubles it. If a CRF 23 export lands at 90 megabytes and you need it under 50, moving to CRF 26 will get you close without a dramatic visual penalty.
Note that CRF scales are codec specific and not interchangeable. CRF 23 in H.265 is meaningfully better quality than CRF 23 in H.264, and VP9 and AV1 use different ranges again. Only compare CRF values within the same codec.
Rather than working out bitrate arithmetic by hand, compress in the browser with a quality slider and see the resulting size before you commit. The file never leaves your device.
Compress a video nowThe Four Levers You Can Pull
Every compression decision comes down to four controls. They are not equally powerful, and pulling them in the wrong order wastes quality you did not need to spend.

Lever one: resolution
Resolution is the most powerful lever available, and the one people are most reluctant to touch. The reluctance is misplaced. Because pixel count scales with area, halving both dimensions removes seventy five percent of the pixels. Going from 4K to 1080p removes seventy five percent. Going from 1080p to 720p removes about fifty six percent.
The key question is not how big the file is but how big the video will ever be displayed. A clip embedded in a blog post at 720 pixels wide gains nothing from 4K. A vertical video watched on phones is displayed at perhaps 1080 pixels tall at most. Any resolution above the display size is data thrown away by the viewer's screen before their eye ever sees it.
One caveat worth knowing: downscaling can actually improve perceived sharpness, because averaging four pixels into one removes sensor noise and compression artifacts. A slightly soft 4K source often looks crisper after being reduced to 1080p than it did at full size.
Downscaling is usually the single biggest size reduction available, and it is a one setting change. Resize to the dimensions the video will actually be displayed at.
Resize a videoLever two: frame rate
Frame rate has a real but smaller effect than resolution, because consecutive frames at high rates are extremely similar and therefore compress efficiently. Halving frame rate typically saves twenty five to thirty five percent rather than fifty.
It is worth doing when the content does not need the frames. Screen recordings of documents, slide presentations, interviews, and static product shots look identical at 30 frames per second and at 60. Gameplay, sports, dance, and anything with rapid camera movement genuinely benefit from 60 and will look juddery if reduced.
Reduce frame rates by whole divisions where possible. Going from 60 to 30 drops every other frame cleanly. Going from 60 to 24 requires the encoder to invent an uneven pattern, which produces visible stutter in panning shots.
Lever three: codec
Switching from H.264 to a newer codec buys real efficiency for free in visual terms. H.265 and VP9 deliver roughly the same quality at thirty five to fifty percent lower bitrate. AV1 pushes that towards fifty percent below H.264.
The cost is compatibility and time. H.265 will not play reliably in every browser, VP9 is strong on the web and weak on devices, and AV1 encodes slowly enough that a long file can take hours. The decision rule is straightforward: if you control the playback environment or you are storing the file for yourself, use a modern codec and take the savings. If someone else has to open it, stay on H.264.
For website video specifically, the compatibility problem largely disappears, because browsers negotiate formats automatically when you provide more than one source.
For video on your own site, a WebM copy typically weighs a third less than the same clip in H.264, which directly improves page speed scores.
Convert MP4 to WebMLever four: audio
Audio is the lever nobody thinks about and it is frequently worth a surprising amount. Uncompressed stereo PCM at 48 kHz and 16 bits consumes about 1.5 megabits per second, or roughly 11 megabytes per minute. That is genuinely significant on a short clip.
Encoded as AAC, that same audio at 128 kbps is under one megabyte per minute and sounds fine to almost everyone. Speech only content is perfectly serviceable at 96 kbps, and mono speech at 64 kbps is still clear. If the audio is not needed at all, removing the track entirely eliminates the cost completely.
| Lever | Typical saving | Risk to quality | Pull it when |
|---|---|---|---|
| Resolution | 50 to 75 percent | None if display size is respected | Source is larger than the viewing size |
| Frame rate | 25 to 35 percent | Judder on fast motion | Content is static or talking head |
| Codec | 35 to 50 percent | Playback failures on old devices | You control the playback environment |
| Audio | 5 to 30 percent | Minimal above 96 kbps | Source has PCM or very high bitrate audio |
Cutting Data Before You Compress
The best compression is the compression you never have to apply. Every second removed and every pixel cropped is data that costs exactly zero bits, with no quality trade whatsoever. This step consistently produces larger savings than fiddling with encoder settings, and it is consistently skipped.

Trim the parts nobody watches
Because file size is bitrate multiplied by duration, cutting duration is a direct proportional saving. Removing thirty seconds from a two minute clip removes twenty five percent of the file, guaranteed, with zero quality cost.
Almost every recording has removable material. Screen recordings begin with the click that started them and end with the reach for the stop button. Phone footage starts before anything happens and runs on afterwards. Interviews contain long pauses and restarts. Cutting is not just a compression technique, it makes the video better to watch, which is why it is the one step with no downside at all.
Cut the dead footage first. It shrinks the file proportionally with no quality loss and makes the video better to watch at the same time.
Trim a videoCrop away unused edges
Cropping removes pixels from every single frame, so the saving compounds across the whole duration. A screen recording of a browser window that captured the entire desktop is spending data on wallpaper and dock icons in every frame. Cropping to the window itself can remove half the pixel area.
Cropping also fixes framing at the same time, which turns a compression task into an editing improvement. If you are reformatting a horizontal video for a vertical feed, cropping is required anyway and the size saving comes along free.
Remove or downmix the audio
Plenty of video does not need sound at all: silent background loops on a website, product demonstrations with on screen captions, screen recordings where the narration was never recorded, footage destined for a feed that autoplays muted. Removing the audio track entirely eliminates its data cost and also removes the risk of a stray sound playing unexpectedly.
Where audio is needed but stereo is not, downmixing to mono halves the audio data. Speech recorded from a single microphone gains nothing from being stored as two identical channels.
Silent background videos and muted social clips do not need an audio track at all. Removing it drops the data and avoids unexpected sound on autoplay.
Remove audio from a videoConsider speed and duration together
For certain content, notably time lapses, long process demonstrations, and tutorial footage with slow sections, speeding up the video shortens the duration and therefore the file. A four minute build process shown at four times speed becomes one minute of video and roughly one quarter of the data, while communicating the same information more effectively.
Speeding up slow sections shortens the runtime, which cuts file size proportionally and usually improves the viewing experience.
Change video speedTarget Settings for Email, Web, and Social
Specific numbers beat general advice. These are practical starting points, not laws, and content complexity will move them in either direction.

Email attachments
Most providers cap attachments at around 25 megabytes, and some corporate systems are stricter still. Target 720p, H.264, roughly 2 to 3 megabits per second, and 96 kbps AAC audio. That combination fits about one minute of video comfortably. If the clip is longer, trim it or send a link, because pushing a five minute video into 25 megabytes requires a bitrate low enough to look genuinely bad.
Website embeds and background video
Page speed is the constraint here, and video is usually the heaviest asset on any page carrying one. Target the actual display width, serve WebM with VP9 as the primary source and MP4 with H.264 as a fallback, and keep a hero or background loop under about 5 megabytes. Mute background video, keep loops short, and make sure the MP4 has its index at the front of the file so playback can begin before the whole file has downloaded.
Social media uploads
The counterintuitive rule for social platforms is not to compress aggressively at all. Every platform re-encodes what you upload, without exception, and their encoder works from whatever you hand it. If you upload a file that has already been squeezed, their compression stacks on top of yours and the result is visibly worse than if you had uploaded a clean file.
Upload MP4 with H.264 and AAC at a generous bitrate, matching the platform's preferred resolution and aspect ratio. Compress only enough to get under the upload size limit, and no further.
Archiving your own footage
Here the calculation flips towards quality, because you cannot recover what you discard. Keep the original resolution and frame rate, use H.265 for the efficiency, and set CRF around 20 or lower. You will get a meaningful size reduction over the camera original while keeping a file good enough to edit or re-export from later.
| Destination | Resolution | Video bitrate | Audio | Codec |
|---|---|---|---|---|
| Email attachment | 720p | 2 to 3 Mbps | 96 kbps AAC | H.264 |
| Website embed | Match display width | 2 to 4 Mbps | 96 to 128 kbps or none | VP9 plus H.264 |
| Social upload | 1080p or platform native | 8 to 12 Mbps | 128 kbps AAC | H.264 |
| Messaging app | 720p | 1.5 to 2.5 Mbps | 96 kbps AAC | H.264 |
| Personal archive | Original | CRF 20 or lower | Original | H.265 |
Rough bitrate guidance by resolution
| Resolution | 30 fps, general use | 60 fps, general use | Static or screen recording |
|---|---|---|---|
| 4K (2160p) | 35 to 45 Mbps | 53 to 68 Mbps | 15 to 20 Mbps |
| 1440p | 16 Mbps | 24 Mbps | 8 Mbps |
| 1080p | 8 Mbps | 12 Mbps | 3 to 5 Mbps |
| 720p | 5 Mbps | 7.5 Mbps | 2 to 3 Mbps |
| 480p | 2.5 Mbps | 4 Mbps | 1 Mbps |
The Step by Step Process
Put together, the whole job is six steps in a specific order. The order matters, because each step reduces the work the next one has to do.
- Start from the original. Find the source export or camera file, not a copy that has already been through a converter or a messaging app. Every previous compression left artifacts that the next round will amplify.
- Delete what you do not need. Trim dead footage, crop unused edges, mute or downmix audio, and speed up slow sections. This is free size reduction with no quality cost.
- Set the resolution to the real display size. Not the largest you have, the largest anyone will actually see. This is usually the single biggest saving remaining.
- Choose the codec by audience. H.264 when someone else must open it, H.265 or VP9 or AV1 when you control playback or are archiving.
- Set quality with CRF or a target bitrate. Start at CRF 23 for general use, and use the tables above as a starting point when the destination has a hard limit.
- Check the busiest moment at full size. Do not judge a compressed file from a thumbnail. Find the section with the most motion and watch it at full screen. If it holds up, you are done. If it breaks up, raise the quality one step and re-encode from the original, never from the failed attempt.
Doing it in the browser
Video compression once required installed software or uploading footage to a stranger's server. Modern browsers removed that requirement: media processing libraries compiled to WebAssembly now run at usable speed inside a tab, which means the file stays on your machine, there is no upload wait, no server imposed size cap, and no question about who else has a copy of your footage.
For anything unreleased, confidential, or simply too large to upload comfortably, that is the better default. The trade is that processing runs on your own hardware, so a long 4K file takes longer on a laptop than it would on rented server capacity.
Compression Mistakes That Ruin Quality

Compressing an already compressed file
This is the single most common and most damaging mistake. Lossy compression is not idempotent: running it twice does not produce the same result as running it once. Each pass discards different detail and introduces its own artifacts, and the second pass then treats the first pass's artifacts as real detail worth preserving while discarding more genuine information.
The symptom is unmistakable once you know it: mushy edges, blotchy color in flat areas, and motion that dissolves into visible blocks. The fix is procedural rather than technical. Keep originals. Compress from them every time. If you need three different outputs, make three passes from the source rather than a chain.
Upscaling to try to recover quality
Increasing the resolution of a low quality video does not add detail, because the detail is gone. It invents pixels by interpolating between the ones that survived, which makes the file larger while making the artifacts bigger and more visible. If a source is 480p, exporting at 1080p produces a larger file that looks worse than the original at its native size.
Ignoring the audio track entirely
People spend an hour tuning video settings and leave a 1.5 megabit per second PCM audio track untouched. On a short clip that can be a third of the file. Always check what the audio actually is before assuming the video is the problem.
Compressing before uploading to a platform
Worth repeating because it is so widespread. Platforms always re-encode. Pre-compressing means your artifacts get compressed again by their encoder, and the result is measurably worse than uploading a clean file. Compress before upload only to satisfy a hard file size limit.
Using constant bitrate out of habit
Constant bitrate exists for live streaming and broadcast, where predictable bandwidth matters more than efficiency. For a file, it wastes bits on easy scenes and starves difficult ones. Variable bitrate or CRF produces better quality at the same size in essentially every offline scenario.
Judging quality on the wrong screen
A compressed video previewed in a small window on a phone will look fine long after it has stopped looking fine on a monitor or a television. Always evaluate at the size and on the kind of screen the video will actually be watched on, and always check the most demanding few seconds rather than a calm opening shot.
Changing frame rate to an incompatible value
Converting 60 frames per second to 24 requires dropping frames unevenly, which introduces stutter that is especially visible in slow camera pans. When reducing frame rate, prefer clean divisions: 60 to 30, 30 to 15, 50 to 25.
Frequently Asked Questions
Can you compress a video without losing any quality at all?
Truly lossless video compression exists but barely shrinks files, so it is almost never used. What is achievable, and what people usually mean, is visually lossless compression: discarding data the eye cannot detect. A well encoded file at half the original size is normally indistinguishable from the original in ordinary viewing.
What is a good bitrate for a 1080p video?
For 1080p at 30 frames per second, 8 megabits per second is a comfortable target for general use and 5 is acceptable for talking head or screen recorded content. At 60 frames per second, raise those to about 12 and 8. Fast motion and fine detail need more, static scenes need less.
What does CRF mean in video compression?
CRF stands for Constant Rate Factor. Instead of fixing the bitrate, you fix a quality level and let the encoder spend whatever bits each scene requires. For H.264 the scale runs from 0 to 51 where lower means better, 18 is visually lossless, 23 is the default sweet spot, and anything above 28 shows obvious artifacts.
How do I compress a video small enough to email?
Most email providers cap attachments at about 25 megabytes. Trim the clip to only the part that matters, downscale to 720p, encode with H.264 at roughly 2 to 3 megabits per second, and set the audio to 96 kbps AAC. That fits roughly one minute of video into the limit. For longer videos, share a link instead.
Does compressing a video more than once make it worse?
Yes. Each lossy re-encode discards detail permanently, and the damage accumulates rather than cancelling out. Always compress from the original file. If you need three different output sizes, produce all three from the source instead of compressing an already compressed copy.
Should I lower the resolution or the bitrate first?
Lower the resolution first if the video is larger than it will ever be displayed. Extra pixels nobody sees are pure waste. Once resolution matches the real viewing size, adjust bitrate or CRF, because at that point every remaining bit is doing visible work.
Which codec compresses video the most?
AV1 is the most efficient codec in mainstream use, roughly 50 percent smaller than H.264 at the same quality, followed by H.265 and VP9 at around 35 to 50 percent smaller. The catch is compatibility and encoding time, which is why H.264 remains the right default for files other people need to open.
Is it safe to compress video in a browser?
Browser based compression that runs locally never uploads your file, so the footage stays on your own machine. That is more private than any service that requires an upload, and it removes server side file size limits. The trade is that processing uses your own hardware, so long 4K files take longer.
Putting It Together
Good compression is mostly a matter of order and discipline rather than deep technical knowledge. Delete what nobody will watch, downscale to what will actually be displayed, choose a codec that matches your audience, set a sensible quality level rather than a guessed file size, and check the result at full size on the busiest section before you delete anything.
Follow that sequence and a typical oversized video loses well over half its weight with no perceptible change. Skip it and reach straight for a quality slider instead, and you will get the same file size with visibly worse footage, which is the outcome everyone is trying to avoid.
If you want to go one level deeper on what the container and codec labels actually mean, our guide to video file formats covers MP4, MOV, MKV, WebM, and AVI in detail. And since audio is the lever most people forget, our guide to audio file formats explains what bitrate, sample rate, and channel count are really costing you.
Quick reference
- Trim, crop, and mute before touching any quality setting. Deleted data is free.
- Downscale to the display size. It is the largest saving available.
- CRF 23 for general use. Add 6 to roughly halve the size, subtract 6 to roughly double it.
- H.264 when others open it, H.265 or AV1 when you control playback.
- Never compress a compressed file. Always go back to the original.
- Do not pre-compress uploads. Platforms re-encode everything anyway.
← Back to all articles
