Is hardware encoding always worse?

No - the gap shows up as bitrate shrinks. At generous bitrates it is essentially invisible; compressing to half size or below is where software quality becomes visibly better. Choose by size budget rather than dogma.

Why does compression in the browser feel so fast?

It is likely WebCodecs hardware encoding - modern Chromium browsers call the GPU encode circuit when available, several times faster than software. Unsupported environments fall back to wasm software encoding automatically, and speed drops accordingly.

Which path is my tool using?

You normally do not need to care - tools probe and fall back automatically. Processing much faster than real-time usually means hardware; slower than real-time means software. Same file, wildly different speeds - the path probably changed.

How it works 5 min read

Hardware vs Software Encoding: Where Speed Trades Quality

Encode the same file twice and one finishes in seconds while the other takes minutes. That is not magic - it is the physical difference between a dedicated circuit and general-purpose computation.

Two paths, two philosophies

Hardware encoders (NVENC, QSV, and friends) are fixed-function circuits on your GPU or chipset. Fixed search space, fixed pipeline - blazing fast and power-efficient, at the cost of narrower compression decisions.

Software encoders like x264 run on general CPU cores and can search harder for better motion estimates and mode decisions. At the same quality target they usually need fewer bits; at the same bitrate they usually keep more detail. The price is time.

How big is the quality gap

A useful rule of thumb: at generous bitrates the difference is invisible to most eyes. As the budget tightens toward CRF 28 territory, hardware output starts to show banding in dark areas and smearing in fast motion first.

So the question is not whether the gap exists but at which bitrate it appears. Plenty of headroom - hardware is fine. Halving or thirding the file size - every extra bit of software search is buying visible detail.

Which path for which job

Previews, test renders while tuning parameters, intermediate files where size does not matter - hardware, because speed is the point. Final delivery, aggressive size targets, quality-sensitive content - software, so every bit lands where it counts.

This site follows the same layering: high-frequency operations use WebCodecs hardware acceleration when the browser supports it, with automatic fallback to wasm software encoding otherwise. You only choose between fast and small.