Compress Video Without Losing Quality: What's Real

"Compress video without losing quality" describes two completely different operations, and only one of them shrinks a file meaningfully. Truly lossless compression reconstructs every original pixel bit for bit. It exists, it is real, and it makes video files larger than you expect rather than smaller, so it is almost never what you want. Visually lossless compression throws away information you cannot see at normal viewing distance, and on ordinary phone or camera footage it routinely cuts the file to a fraction of its original size while looking identical on the screens people will actually watch it on. The pixels change. Your eyes do not notice. Anyone promising a large reduction with zero loss is quietly describing the second thing while using the vocabulary of the first. The practical question is not whether you lose data. You do. It is how far you can push before the loss becomes visible on your specific footage, and that answer is a number you can find in about four minutes.

The rest of this page is the distinction in detail, why phone footage has so much room to give, the quality settings that sit at each point on the scale, the content types that punish compression hardest, and the check to run before you delete the original.

What would lossless compression actually mean?

Lossless means bit exact. Decode the compressed file, compare it to the source frame by frame, and every pixel matches. The x265 command line documentation describes its own lossless mode plainly: it bypasses "scaling, transform, quantization and in-loop filter processes," and "reconstructed output pictures are bit-exact to the input pictures." That is the real definition, and it comes with the consequence stated in the same place: lossless encodes have no rate control at all. You do not get to ask for a size. You get whatever size mathematically encoding every original pixel requires.

The FFmpeg H.264 encoding guide is blunter about the practical outcome. Its lossless section warns that "lossless output files will likely be huge, and most non-FFmpeg based players will not be able to decode lossless. Therefore, if compatibility or file size are an issue, you should not use lossless." When your reason for compressing is that a file will not fit somewhere, lossless video encoding is the wrong tool by definition.

There is one genuinely lossless operation that does reduce file size, and it is worth knowing because it is free and instant: cutting. Trimming a video with a stream copy removes seconds of data without touching a single pixel of what remains. Nothing is re-encoded, so nothing degrades. It only works at keyframe boundaries, which is why the cut point snaps, and we covered exactly why in how keyframes decide where a lossless cut lands. Rewrapping a file from one container to another, say MOV to MP4, is the same idea: the video stream is copied across untouched. You get a different wrapper, better compatibility, and almost no size change, because the bytes that make up the picture are all still there.

So the honest summary is short. If nothing is re-encoded, nothing is lost and almost nothing is saved. If a lot is saved, something was re-encoded and something was lost. Everything interesting lives in what that something is.

Why does phone footage shrink so much with no visible change?

Because the encoder inside your phone was never trying to make a small file. It was trying not to drop frames.

A camera encodes in real time, on a battery-powered block of silicon, while the sensor keeps delivering new frames whether the encoder is ready or not. It cannot pause to search a dozen reference frames for a better motion match. It has to commit to a decision for every macroblock at capture speed, and it has to hold enough bitrate in reserve for the hardest second in the clip, because it does not know in advance whether you are about to pan across a tree line. The result is a file that is generously specified and full of redundancy a patient encoder can remove.

Re-encoding afterwards removes exactly that constraint. The FFmpeg guide's preset advice captures the trade in one line: "A slower preset will provide better compression (compression is quality per filesize)," and the recommendation is to "use the slowest preset that you have patience for." A slow preset spends more seconds per frame looking for redundancy, and that search is where free savings come from. Nothing about the picture is being sacrificed when a slower search finds a cheaper way to describe the same block.

This is the headroom that makes "no visible change" plausible on phone footage in a way it is not on, say, a file you already compressed once for the web. A clip straight off a camera has slack. A clip that has already been squeezed does not, and the second pass takes its savings out of picture quality instead.

Worth being straight about one thing here: the encoding on this site runs in your browser on your own CPU, so it uses a fast preset to stay usable on a laptop rather than the slowest one available. A desktop FFmpeg run at -preset slow will beat it slightly at the same quality setting. The difference is small, and the trade is that your file never leaves your machine.

What CRF is visually lossless for your content type?

CRF, the constant rate factor, is the quality dial. You ask for a quality level and the encoder spends whatever bitrate that level needs, frame by frame. Simple frames get cheap, complex frames get expensive, and the file size falls out at the end. The size arithmetic underneath it, bitrate times duration, is worked through in video compression by the numbers.

The FFmpeg guide gives the scale precisely. For 8-bit H.264 the range is 0 to 51, "where 0 is lossless, 23 is the default, and 51 is worst quality possible," with a "subjectively sane range" of 17 to 28. On the top end of quality it is specific: "Consider 17 or 18 to be visually lossless or nearly so; it should look the same or nearly the same as the input but it isn't technically lossless." That last clause is the whole article in five words.

The other documented fact you need is how the scale behaves. It is exponential: "increasing the CRF value +6 results in roughly half the bitrate / file size, while -6 leads to roughly twice the bitrate." That rule is what lets you reason about sizes without encoding anything first.

Here is the worked comparison, expressed the only honest way it can be. Actual megabytes depend entirely on your source clip, its length, its resolution and how busy the picture is, so the sizes below are relative, derived from the halving rule above rather than measured on your footage. What is fixed and worth memorising is the right-hand column.

CRF	Where it sits	Roughly what happens to size	What to look at to spot the difference
18	Visually lossless or near it	Reference point for this table	Nothing should be visible. If you can see softness here, your source was already compressed hard, and re-encoding is not your problem.
23	The default, sane middle	Five steps up the scale, so just short of one halving against CRF 18	Pause on a fast pan. Check edges of moving objects for a faint shimmer, and check any large smooth gradient, a sky or a painted wall, for the first hint of stepping.
28	Top end of the sane range	Ten steps up, so approaching a quarter of the CRF 18 size	Look at the darkest scene first. Blocking shows in shadows before anywhere else. Then check fine texture in motion: hair, foliage, fabric weave, water.

Two things follow from that table. First, the jump from 18 to 23 buys a large share of the total available savings while staying invisible on most real footage, which is why 23 is the default. Second, the payoff for going from 23 to 28 is smaller in absolute megabytes than the first jump was, because each step is a proportion of a shrinking number, and the visible cost is higher. That asymmetry is the reason "compress harder" stops being a good deal quickly.

The compressor on this site exposes three points rather than a raw slider: high quality at CRF 23, balanced at 28, and smallest at 32. If you want the closest thing to the comparison above that you can run yourself in a couple of minutes, encode the same clip at high quality and at balanced, then compare the two outputs on the hardest scene in the video. Naming what you actually need in plain English is what the settings advisor is for.

Which content punishes compression hardest?

The picture types that break first are consistent, and they are all cases where the encoder cannot find redundancy to remove.

Grain and sensor noise. Noise is random by definition, so nothing predicts it, and the encoder either spends enormous bitrate preserving it or smears it into blotches. Low-light footage from a phone is mostly this.

Wide smooth gradients. Skies, studio backdrops, colour washes behind a title. MDN's video codec guide names the failure precisely: "contouring or color banding is a specific form of posterization in which the color blocks form bands or stripes in the image," and it "occurs when the video is encoded with too coarse a quantization configuration." A sunset that looked continuous develops visible rings.

High-frequency motion. Confetti, rain, water, leaves in wind, a crowd. Every frame differs everywhere at once, so inter-frame prediction has nothing to lean on.

Hard edges over flat backgrounds, which includes screen recordings, slides and subtitles. The MDN guide to web video codecs calls the artifact ringing, "an effect where areas outside an object are contaminated with colored pixels generated by the compression algorithm." On text it reads as a faint halo, and it is the one artifact viewers notice consciously.

Dark scenes, for a reason worth separating from the others. See the FAQ below.

Against those, the easy cases are static talking heads, locked-off product shots, and screen recordings where most of the frame does not change between frames. Those tolerate a much higher CRF than the table suggests, and the difference between content types is larger than the difference between any two adjacent settings.

How do you check before you keep the smaller file?

The check that matters takes four minutes and is not "watch the whole thing".

1. Find your worst frame first. Scrub for the darkest scene, the fastest pan, or the widest gradient. Whatever the hardest second in the clip is, that is your test. Judging quality on a static opening shot tells you nothing.
2. Compare at the size people will watch it. A file destined for a phone screen in a chat app does not need to survive a full screen 27 inch monitor at 100 percent zoom. Judging at the wrong scale is how people talk themselves into files three times bigger than the job needs.
3. Put the two files side by side, not one after the other. Open the original and the compressed copy in two windows, paused on the same frame. Sequential viewing flatters the second file every time, because your memory of the first one is generous.
4. Check the audio. It is easy to forget that a re-encode touches the soundtrack too. Listen to a few seconds with any music in it.
5. Keep the original until you have shipped. Compression is not reversible. There is no way back to detail that was thrown away.

If the compressed file passes on the worst frame at the intended viewing size, it will pass everywhere else in the clip.

Frequently asked questions

Is any video compression truly lossless?

Yes, and you almost certainly do not want it. True lossless modes exist in both x264 and x265, and they reconstruct the source bit for bit. The FFmpeg guide notes that the files are huge and that many players cannot decode them, so it advises against lossless whenever compatibility or file size matters. The genuinely lossless operations worth using are the ones that avoid re-encoding entirely: trimming with a stream copy, rewrapping into a different container, and removing an audio track. Those change the file without touching a pixel of the video that remains.

What CRF should I use for 1080p?

Start at 23, the encoder's own default, and adjust from what you see rather than from a rule. Move toward 18 for footage with grain, dark scenes or wide gradients, and for anything you may need to re-edit later. Move toward 28 for talking heads, screen recordings and clips heading for a phone screen. The FFmpeg guide's advice is the right process: "choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value. If it looks bad, choose a lower value." Resolution matters less to this choice than content does. A noisy 1080p handheld clip needs a lower CRF than a clean 4K screen recording.

Does compressing twice compound the damage?

Yes. Each lossy encode works from what the previous one left behind, so the second pass cannot recover detail the first pass discarded, and it adds its own quantization on top. MDN puts the general rule simply: "the more compression you achieve, the more loss of detail and fidelity will occur." The practical effect is that artifacts introduced by the first encode, banding in a sky, blocking in a shadow, become features of the picture that the second encode faithfully preserves and then degrades further. Always compress from the highest quality source you have rather than from an already-compressed copy, and if you need a different size, go back to the original and re-encode it once rather than squeezing the squeezed file.

Why do dark scenes look blocky after compressing?

Two reasons stack. Dark regions occupy a small slice of the available code values, so the same quantization step that is invisible in a bright scene lands as a visible jump between adjacent shadow tones. And dark footage from small sensors carries the most noise, which the encoder either preserves at high cost or averages away into flat patches. The result is what MDN describes as posterization: "instead of smooth transitions through the various colors in a region, the image becomes blocky, with blobs of color." If your clip has a dark scene that matters, set your quality by that scene and accept a larger file for the rest, or brighten the shadows slightly before encoding so the detail sits in a range the encoder spends bits on.

Run the two encodes and look

The argument is settled in less time than reading about it takes. Compress the same clip twice at two different quality settings, open both against the original on the hardest frame in the video, and decide with your own eyes where your footage stops looking the same. Compress a video here and both outputs land in your downloads folder. The file is read into browser memory and encoded on your own CPU, so nothing is uploaded and nothing sits in a queue.

The free tier handles inputs up to 200 MB and adds a small watermark in the corner of video exports. Pro removes both, adds compression to an exact target size, instant lossless trim and mute, contact sheets and the settings advisor, and costs $4 a month billed as $24 every six months, or $79 once for life. If your problem is a specific number rather than a quality level, hitting an exact file size is a different calculation and has its own walkthrough.