x264 vs x265: The Encoder Comparison That Actually Matters
x264 vs x265: The Encoder Comparison That Actually Matters
Most x264 vs x265 comparisons tell you that x265 makes smaller files and takes longer. That is true, and it is also the least useful part of the answer, because it does not help you decide anything.
The parts that actually change your outcome are subtler: the two encoders use different CRF scales, so identical numbers mean different quality targets. The bitrate savings vary enormously by content type. And the encode-time penalty is not a fixed multiplier — it depends heavily on preset, and preset interacts with the efficiency gain in ways that occasionally erase it entirely.
This guide covers what you need to actually make the call.
First: They Are Encoders, Not Codecs
This trips up a lot of people, and getting it straight makes everything else clearer.
- H.264 (AVC) and H.265 (HEVC) are standards. They define the bitstream format a decoder must understand.
- x264 and x265 are encoders — specific open-source software implementations that produce conforming bitstreams.
The distinction matters because x264 and x265 are not the only encoders for those standards. Your GPU has hardware encoders for both. Your Mac's media engine has them. They all produce valid H.264 and HEVC, at very different quality-per-bitrate and speed. So "H.265 is 50% more efficient than H.264" is a statement about the standards; "x265 gives me 35% smaller files than x264 at the same quality" is a statement about these two specific implementations at specific settings — and only the second one is actionable.
x264 and x265 both happen to be reference-grade. x264 in particular is widely regarded as the best H.264 encoder in existence, which is worth remembering: when you compare x264 against x265, you are comparing an extremely mature, heavily tuned encoder against a newer one. That flatters x264 relative to what the H.264 standard alone would suggest.
If any of this is unfamiliar, what a video codec is is the right starting point, and HEVC vs H.264 covers the standards themselves rather than the encoders.
Compression Efficiency: The Real Numbers
The headline claim for HEVC is "half the bitrate at the same quality." That figure comes from the standardisation process and represents a best case under specific test conditions.
In practice, comparing x265 against x264 at comparable presets and quality:
| Content type | Typical bitrate saving |
|---|---|
| High-resolution, detailed, high-motion (4K action, sport) | 40–50% |
| Standard 1080p mixed content | 25–40% |
| Low-motion, flat content (screencasts, talking head) | 15–30% |
| Already low-bitrate / heavily compressed source | Often negligible |
Two patterns drive this:
x265 gains most at high resolution. HEVC's larger coding units — up to 64×64 versus H.264's 16×16 macroblocks — pay off on large flat regions, which are far more common in 4K frames than in 480p ones. At low resolutions the advantage narrows sharply, and at very low resolutions x264 can be competitive.
x265 gains most at low bitrates. At high bitrates both encoders have enough budget to represent the frame well, so the efficiency gap compresses. HEVC's advantage is largest exactly where you are starving the encoder.
The practical implication: if you are transcoding 4K down to a constrained bitrate, x265 is a large win. If you are lightly compressing 1080p that is already reasonably encoded, the win may not justify the time.
The CRF Trap
This is the single most common source of bad x264 vs x265 conclusions, so it deserves its own section.
Both encoders default to CRF — constant rate factor — which targets a consistent perceptual quality rather than a fixed bitrate. Lower CRF means higher quality and bigger files.
The scales are not the same between encoders.
- x264's default is CRF 23
- x265's default is CRF 28
Those defaults are chosen to land in roughly comparable quality territory. Which means if you take your habitual -crf 23 from x264 and pass it to x265, you are not doing a like-for-like comparison — you are asking x265 for substantially higher quality, and getting a bigger, slower encode than you expected. Conversely, people who compare x265 at CRF 28 against x264 at CRF 23 and declare "x265 looks softer" are sometimes comparing a lower quality target against a higher one.
A reasonable rule of thumb for rough parity is x265 CRF ≈ x264 CRF + 5, but treat that as a starting point rather than a law — it drifts with resolution, content and preset. The only reliable method is to encode a representative 30-second clip at two or three CRF values and look at them.
Encode Time
x265 is slower. How much slower depends almost entirely on preset.
Both encoders expose the same preset ladder — ultrafast through placebo, with medium as default — and the preset controls how much analysis the encoder performs per frame. But the presets do not mean identical things across the two encoders. x265's medium does considerably more work than x264's medium, because HEVC has more tools to evaluate: more prediction modes, more transform sizes, and a recursive coding-unit structure that must be searched.
Rough expectations at comparable presets and quality:
| Preset | Relative encode time (x265 vs x264) |
|---|---|
veryfast | ~1.5–3× slower |
medium | ~3–6× slower |
slow / slower | ~5–10× slower |
veryslow | 10×+ slower |
There is an important consequence buried in that table. A faster x265 preset can lose to a slower x264 preset. x265 at ultrafast throws away most of what makes HEVC efficient; x264 at slow is exploiting nearly everything H.264 has. If you are constrained on time, cranking x264's preset up is sometimes a better use of the same minutes than switching encoder and dropping the preset to compensate.
If encode time is your binding constraint, the more effective lever is usually not the preset at all — it is moving to a hardware encoder. That trade-off is covered in hardware vs software video encoding.
Compatibility
This is where x264 still wins decisively, and it is a practical concern rather than a theoretical one.
H.264 plays essentially everywhere. Every browser, every phone made in the last fifteen years, every smart TV, every editing application, every social platform's upload pipeline. If you encode H.264 and hand the file to someone, it works.
HEVC support is broad but not universal.
- Apple — full support across Safari, macOS, iOS and Apple TV, with hardware decode on every recent device.
- Windows — hardware decode is standard on modern GPUs, but the OS may require a HEVC extension for some playback paths.
- Browsers — Safari yes; Chrome and Edge support HEVC where hardware decode is available; Firefox's support arrived later and depends on platform.
- Older devices — anything more than a few generations back may decode HEVC in software, badly, or not at all.
- Editing software and platform uploads — generally fine now, but HEVC in a MOV container from an iPhone still confuses older tools.
There is also the licensing dimension. H.264's patent situation is mature and well-understood. HEVC's is famously fragmented across multiple patent pools, which is precisely why the industry funded AV1 as a royalty-free alternative. For an individual encoding personal files this changes nothing; for anyone distributing video commercially at scale, it is a real cost line.
10-Bit Encoding
One genuine x265 advantage that gets underplayed: 10-bit encoding is standard and cheap in HEVC, whereas in H.264 it lives in a High 10 profile that many hardware decoders do not support.
Encoding 8-bit source at 10-bit depth is not about displaying more colours. It reduces banding in gradients — skies, fades, shadow detail — because the encoder's internal precision is higher, so rounding errors accumulate less. It often improves compression efficiency slightly at the same time.
x265 defaults to 10-bit in most modern builds. If you are encoding anything with smooth gradients, this alone can be worth the switch.
Which Should You Use?
Use x264 when:
- The file must play on unknown or older hardware.
- You are encoding for a platform that will re-encode anyway (YouTube, most social media) — send it good H.264 and let them do the work.
- Encode time matters more than file size.
- You are working at 1080p or below with a generous bitrate budget.
Use x265 when:
- You are archiving, and storage matters more than the hours spent encoding.
- The source is 4K or higher.
- You control the playback environment — Apple ecosystem, your own devices, a known device fleet.
- Bandwidth or storage cost is the binding constraint.
Consider AV1 when: you are delivering at scale on the web, can absorb slower encoding, and your audience is on reasonably current hardware. See AV1 vs H.265 for that comparison.
The Easier Path on a Mac
Everything above assumes you are driving an encoder directly — command-line x265, or HandBrake with the advanced panel open. That is the right approach when you need precise control, and our FFmpeg compression guide covers the syntax.
But most of the time the goal is not "produce an optimally tuned HEVC stream." It is "make this file small enough, without it looking bad." For that, choosing an encoder and hand-tuning CRF is a lot of ceremony.
Compresto handles the encoder choice for you on macOS. It uses Apple's hardware media engine where that is the right call and falls back to software encoding where quality demands it, targets a size or quality level you actually care about, and processes whole folders in batch. Everything runs locally — nothing is uploaded.
If you want the control, use x265 directly. If you want the result, this is faster.
Frequently Asked Questions
Does x265 reduce quality compared to x264?
Not inherently. At a properly matched quality target, x265 produces a comparable-looking file at a smaller size. Perceived quality drops usually come from comparing mismatched CRF values, or from using a very fast x265 preset that skips the analysis HEVC depends on.
Why is my x265 file bigger than my x264 file?
Almost always a CRF mismatch — x265 CRF 23 is a much higher quality target than x264 CRF 23. Try adding about 5 to your x265 CRF value. A very fast preset can also produce this result.
Is x265 free to use?
The x265 encoder itself is open source under the GPL. Patent licensing for the HEVC standard is a separate matter, and relevant to commercial distributors rather than individuals encoding their own files.
Can I convert existing x264 files to x265?
You can, but it is lossy re-encoding — you are decoding an already-compressed file and compressing it again, so quality only goes down. It is worth it for large archives where the storage saving matters; it is not worth it for files already at a reasonable size. See converting HEVC to H.264 for the reverse direction.
What about hardware HEVC encoders?
NVENC, Quick Sync and Apple's VideoToolbox all encode HEVC dramatically faster than x265, with somewhat lower efficiency at a given quality. For most practical purposes the gap has narrowed a lot — see hardware vs software video encoding.