A browser video compressor I use at work added H.265 to its MP4 export, and I wanted to know what actually happens when you pick it. The answer on one Apple M4 Mac with macOS 26.5 and Chromium 149: with the hardware encoder it takes 4 to 9 seconds per minute-long 1080p clip, and the files come out 19 to 30% smaller than H.264 at the same preset. Take the hardware encoder away and it depends on what you feed it. An H.265 source falls back to x265 running in WebAssembly, which took 55.5 seconds instead of 8.5. An H.264 source gets no fallback at all.
I used ImgIng (https://imging.ai/), whose video compressor runs inside the tab, on the live site on 2026-10-19, with two 60-second 1080p30 clips. The first is a street guitar performance from Wikimedia Commons, "Ljubljana Street Country Guitar Performance" by Isak Zvegelj (CC BY 3.0), which I cut to a minute and re-encoded at a phone-like bitrate, so it ends up at 122,317,449 bytes. It is not a phone original. The second is a lecture-style screen recording I generated frame by frame, 45,881,903 bytes, and it is stiller and cleaner than a real one. Every job ran once. I scored the outputs against the source with ffmpeg's libvmaf, where 100 means indistinguishable.
The hardware path is quick and about a fifth smaller
| Clip and preset | H.264 bytes | H.265 bytes | Change | H.265 time |
|---|---|---|---|---|
| Guitar, HD balanced | 57,160,300 | 46,131,638 | −19.3% | 8.5 s |
| Guitar, smallest size | 10,487,546 | 7,850,182 | −25.1% | 4.0 s |
| Screen, HD balanced | 9,360,304 | 6,584,709 | −29.7% | 8.5 s |
| Screen, smallest size | 10,045,764 | 7,732,118 | −23.0% | 3.9 s |
The "HD balanced" preset keeps the long side at 1920 px or less and caps frame rate at 30. At that preset the H.265 guitar file scored 96.67 against 97.16 for H.264, and the screen recording went the other way, 98.42 against 98.03. On these two clips I couldn't find a quality price for the smaller file. The capability panel next to the format list said the H.265 output was native hardware, and the finished files carry only a "Compressed locally in the browser with ImgIng" note in their metadata. One thing that had me re-checking my numbers for a while: the interface counts a MB as 1024×1024 bytes, which is why 46,131,638 bytes shows up as 43.99 MB on screen. Across all 21 jobs the network log showed no requests other than GET, so nothing was uploaded.
Without the hardware encoder the source format decides
Next I turned off hardware video encoding in Chromium to see the fallback. That is an artificial setup. I don't have a real machine without an HEVC encoder, so how one of those behaves is still an open question for me. The panel's line for H.265 output showed three different states over that afternoon: native hardware, local WASM, and not available on this device. Which of the last two you get depends only on the file you drop in.
With an H.265 source, a 20,645,740-byte H.265 copy of the screen recording, the panel switched to "local WASM" and a note explained that it would load a shared high-fidelity core on demand and use x265 to keep H.265, the source bit depth, resolution, frame rate and colour curves. It then fetched a 25,328,759-byte ffmpeg-core.wasm plus some JS. The whole job took 55.5 seconds including that first download, against 8.5 seconds on hardware, roughly 6.5 times longer. The output was 5.73 MB against 6.01 MB from hardware, with VMAF 97.97 against 98.32. My guess is that software x265 simply searches harder, but I can only see the result, not the reason.
With an H.264 source there was no such path. The panel listed H.265 output as not available on this device, and the tool pointed me to MP4 with H.264 or to WebM instead. I had read the site's line about loading x265 when hardware is missing as covering every source, and it turns out to cover only files that are H.265 already. Fair enough, but I'd have liked to know that before I set the test up. So on a machine like this the panel matters more than the format list. For a phone clip that is already H.264, the realistic choices are H.264 or WebM. A file that is already H.265 still comes out as H.265, just about a minute later.
What I check now
The H.265 files themselves played in Chromium 149, Chrome 155, Firefox 151 and a macOS WebKit 26.5 build on the same Mac. A stripped-down Chromium build showed no picture and raised no error, and its canPlayType returned an empty string for HEVC, so asking first would have caught it. Windows, Android and iPhone Safari I didn't test.
Before trusting H.265 export on a new machine, I run one short clip and read the capability panel. If it doesn't say hardware and my source is H.264, I stay on H.264. When the file is headed for a web page, I keep an H.264 copy next to it and call canPlayType before choosing which one to serve.
Top comments (0)