"How do I compress a video without losing quality?" is one of the top-searched video questions of any given year, and the honest answer starts with a distinction most tools skip: what you almost certainly mean by "without losing quality" is visually lossless, not mathematically lossless. Visually lossless says "the compressed version looks identical to the original when you sit at a normal viewing distance." Mathematically lossless says "the compressed file, decoded, produces the exact original pixels down to the last bit." The two are very different problems, and only the first one is worth solving for a typical video.
#Why mathematically lossless is almost never what you want
Truly lossless video compression exists - FFV1 and Ut Video and lossless HEVC are real codecs - but the compression ratios are modest. A 4K 10-bit clip that is 60 GB uncompressed lands around 20-30 GB in FFV1 and around 5-8 GB in HEVC lossless. Compared to a visually-lossless HEVC encode at the same quality, which lands around 1-2 GB, mathematical losslessness costs an order of magnitude in file size for a quality difference you cannot see. Post-production archives use lossless. Everything else uses visually lossless.
#The three levers
Every video compression decision comes down to three variables: resolution, bitrate, and codec. You get to move any of them; a good compression job moves the ones that matter and leaves the rest alone.
Resolution
The most quality-preserving lever people never touch. If you shot 4K but the video will be viewed on phones, a 1080p downscale keeps every pixel of detail those phones can display and cuts the file by three-quarters. A 4K → 1080p downscale done through a good scaler (Lanczos, bicubic) is essentially invisible on a phone screen and looks fine on a laptop. It is only visible on a 4K TV at a close viewing distance.
Bitrate
The lever most tools focus on and most users move too aggressively. Bitrate is bits-per-second - how much data the encoder has to describe each frame. Higher bitrate = more detail preserved. Every codec has a "visually transparent" bitrate range for a given resolution: above it you are wasting bits, below it you start losing detail your eyes can see.
Rough visually-transparent bitrate targets for H.264 at 30 fps:
- 720p: 3-5 Mbps
- 1080p: 6-10 Mbps
- 1440p: 12-18 Mbps
- 4K SDR: 25-40 Mbps
- 4K HDR: 45-70 Mbps
HEVC roughly halves those numbers. AV1 roughly two-thirds them. If your camera writes 100 Mbps at 4K SDR (many modern phones do), you are already above the visually-transparent range - you can drop to 30 Mbps with no visible loss.
Codec
Changing codec at the same visual quality is a free file-size win. HEVC at 5 Mbps looks like H.264 at 8 Mbps. AV1 at 4 Mbps looks like HEVC at 5 Mbps. If you are transcoding anyway, going from H.264 to HEVC is a large size drop with no visible quality change. See the codec comparison for the trade-offs.
#The playbook
- Step 1: figure out what "the original" actually is. Does your source file need to shrink because the file is bigger than you need (an iPhone 4K clip you want to share on WhatsApp), or because you want to store more of them (a screen-recorder archive)? The answer changes which lever you pull.
- Step 2: pick the resolution the file will actually be viewed at. A phone clip going to another phone: 1080p is plenty; 720p is often enough. A talking-head recording going to YouTube: 1080p is the max Google will preserve on non-premium tiers. A cinematic archive: keep the source resolution.
- Step 3: pick the bitrate for that resolution. Use the table above as a starting point. If you are unsure, start on the low end of the transparent range and eyeball the result at 100% zoom on the intended device. If it looks fine, you are done. If it looks blocky in high-motion scenes, bump up 20% and try again.
- Step 4: pick the codec your target actually plays. Phone-to-phone: HEVC is fine (both ends probably decode it). Web upload: H.264 is the safe choice.
#Where Wave fits into this, honestly
Wave's specialty is the case where compression is not needed at all: your source is an MKV or MOV or TS or MTS carrying H.264 or HEVC, and you just want it in an MP4 that plays on iPhone. Wave remuxes - it rewrites the container without touching the compressed streams inside, so the file size stays essentially the same and the quality stays literally identical.
Wave is not the right tool for a bitrate-driven shrink. If you want a 500 MB source down to 100 MB, Wave will happily convert it and produce a file around the same size (remux) or slightly smaller (re-encode with WebCodecs H.264 at reasonable defaults, but no per-file bitrate tuning). For serious bitrate compression with quality control, use a desktop encoder - HandBrake and Shutter Encoder are both free, both use x264 / x265 with tuning knobs, and both let you set a specific bitrate target with two-pass encoding.
#What NOT to do
Do not upload to a "compress video online free" site that offers a slider from 1 to 100. The slider hides what is actually happening: it is picking a bitrate, and 100 is "close to the source" while 1 is "unwatchable." A meaningful control asks you for a target bitrate or a target size, not a mystery number.
Do not double-compress. Every re-encode is lossy. A file that has been through H.264 → H.264 twice is visibly worse than one that was H.264 once, even at the same bitrate. If you can, compress from the highest-quality source you have (the original camera file, not a copy that was already re-encoded to email-friendly size).
Do not compress a source that has already been compressed hard. A 500 MB clip that started life as a 20 GB camera file is already close to its transparent-quality floor. Compressing it further hits diminishing returns fast and starts showing artefacts before the file gets much smaller.
#The takeaway
Compress by picking the right resolution, the right bitrate for that resolution, and the most efficient codec your target can play. Do it once, from the highest-quality source. Do not double-compress. Do not trust a "quality slider" without a bitrate number attached. And when your only real problem is that the container will not play on iPhone, don't compress at all - remux it and keep every bit of quality you started with.