Convert HEVC to H.264: Quality, File Size and HDR

That is the whole answer. The rest of this page backs it up with a test I ran before writing it: one standard-range clip and one HDR clip, both HEVC, both converted with the same settings this site's converter uses. You get the real sizes, what happened to the colour, and the one extra step HDR footage needs.

Why is there no lossless way from HEVC to H.264?

Because they are different compression languages. A video codec does not store pictures. It stores instructions for rebuilding them: how to predict a block from its neighbours, how to move chunks between frames, which fine detail to throw away. HEVC (H.265) and H.264 use different block structures and different prediction rules. A stream written in one cannot be handed to the other as is.

That is why a quick "convert" that finishes in a second is not converting the codec at all. Changing the container (MOV to MP4) is a rewrap, which copies the compressed video untouched. If the video inside is HEVC, it is still HEVC afterwards, and the same players that choked on it will choke on the MP4. Our guide on MOV to MP4 covers how to tell which case you have.

A real codec change has to decode every frame to raw pictures and encode them again. The decode is exact. The encode is lossy, because H.264 will always discard some detail to hit its size target. So "lossless" conversion between these two codecs is a marketing phrase. What you can honestly aim for is a conversion where the loss is smaller than anything you or your audience could see.

Two practical points follow from this:

• Keep your HEVC original. It is the smaller, cleaner master. Make the H.264 file as a copy for wherever it has to play.
• Convert once, from the original. Converting an H.264 copy again stacks a second round of loss on the first.

If you are not sure why your clip will not open in the first place, the usual cause is a missing decoder rather than a broken file, and we walk through that in iPhone videos not playing on PC. For the codec trade-off itself, see H.264 vs H.265.

Why does the H.264 file come out bigger?

HEVC was designed to deliver similar picture quality in a smaller file, and phones lean on that: they record HEVC at a fairly modest bitrate because the codec makes it look good. When you re-encode to H.264, the encoder has to spend more bits to look equally good, and if you ask for high quality it will spend them.

The settings matter here. This site's converter uses constant-quality encoding (CRF 21) rather than a fixed bitrate. CRF means "hold this quality level and let the size fall where it falls". It does not aim at the size of your original, so a clip that was cheap in HEVC can cost noticeably more in H.264. The compression guide video compression by the numbers explains how bitrate, duration and size relate if you want the arithmetic.

Here are the sizes from my test. I made two 5-second, 1920x1080, 30 fps test clips with FFmpeg 8.1.2 on my desktop: a synthetic test pattern with film-style noise added, encoded as HEVC at CRF 28 to stand in for a phone clip. One is standard 8-bit video. The other is 10-bit with HLG HDR tags, the same kind of signal recent iPhones record. I then converted both with the same encoder settings the VidClip converter passes to FFmpeg: libx264, veryfast preset, yuv420p, CRF 21, AAC audio at 128 kbps.

Clip	HEVC original	H.264 at CRF 21	Change
Standard range, 8-bit	2.55 MB	4.16 MB	about 63% larger
HDR (HLG), 10-bit	2.54 MB	4.52 MB	about 78% larger
HDR, tone mapped to standard range first	2.54 MB	3.62 MB	about 43% larger

Treat those as one data point, not a rule. A noisy synthetic clip is a hard case for any encoder, my "phone" originals were encoded at a different quality target than a real phone uses, and real footage with calm backgrounds compresses very differently. What does carry over is the direction: converting a modern phone clip to H.264 at a high quality setting makes the file larger, and it is not a sign that anything went wrong. If the size matters, a lower-quality setting shrinks it, at the cost of detail. That trade is the subject of compressing video without losing quality.

What happens to 10-bit HDR footage?

This is the section most converter pages skip, and it is the reason people end up searching for "hevc 10 bit to h264".

Recent iPhones record HDR video by default on supported models. Apple's guide to changing video recording settings on iPhone says the phone records in HDR and that other devices receive an SDR version when you share it from the phone. If you copy the file off with a cable instead, you get the HDR original. Android flagships have similar modes. That HDR footage is 10-bit, with a wide colour gamut and a brightness curve (HLG or PQ) that the player is expected to understand.

H.264 can carry 10-bit video, but almost nothing outside editing software plays it. The common, safe H.264 is 8-bit yuv420p. So when you convert, you make two separate decisions: the bit depth (10-bit down to 8-bit) and the colour handling (keep the HDR signal, or map it to standard range).

I ran both on my HDR test clip and probed the results with ffprobe:

Stage	Video codec and profile	Pixel format	Colour tags
HDR original	HEVC Main 10	yuv420p10le	BT.2020 primaries, HLG transfer
Plain conversion (what the browser tool does)	H.264 High	yuv420p (8-bit)	BT.2020 primaries, HLG transfer, carried across
Tone-mapped conversion (desktop FFmpeg)	H.264 High	yuv420p (8-bit)	BT.709, standard range

The plain conversion kept the HDR colour tags and the brightness values. I measured the average luma of one frame: the HDR original read 502.6 on the 10-bit scale, which is 125.6 on an 8-bit scale, and the plain H.264 output read 125.7. In other words nothing was remapped. A player that reads the BT.2020 and HLG tags will display it as intended. A player that ignores the tags treats the numbers as ordinary standard-range video, and that is the washed-out, low-contrast look people complain about.

To be exact about this site: VidClip's converter outputs 8-bit H.264 with AAC audio and does no HDR tone mapping. It is built on the FFmpeg WebAssembly build in your browser, and the tone-mapping step needs filters it does not run. I checked the 8-bit result and the colour tags carrying across against the same settings on desktop FFmpeg, not by running the browser tool itself, so treat the numbers above as what those encoder settings do rather than a measurement of the web page.

The fix for HDR clips has three options, in order of effort:

1. Turn HDR off at the source. On an iPhone, Settings, Camera, Record Video, then turn off HDR Video. New clips come out as standard video that looks the same everywhere. This only helps for clips you have not shot yet.
2. Convert with the browser tool and check the result on the device where it needs to play. Many modern players read the tags and look right. If yours does not, go to option 3.
3. Tone map on the desktop. This remaps the HDR brightness and gamut into standard range properly. The command below does it with FFmpeg's zscale and tonemap filters, which are documented in the FFmpeg filters reference:

ffmpeg -i input.mov -vf "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" -c:v libx264 -preset slow -crf 20 -c:a aac -b:a 128k -movflags +faststart output.mp4

I ran that chain on the HDR test clip (with veryfast and CRF 21 to match the table above). The output reported BT.709 tags and 8-bit yuv420p, and the file size was 3.62 MB. Note that it needs an FFmpeg build with the zscale filter, which the common full builds include. Tone mapping is a judgement call, not a lossless step: highlights are compressed to fit, and hable is one of several curves FFmpeg offers. For a family video it is a sensible default.

Which quality setting hides the re-encode?

CRF is the dial. Lower numbers keep more detail and produce bigger files, higher numbers do the opposite. For the x264 encoder, values around 18 to 23 are the usual working range, with the low end for anything you care about and the high end for chat clips.

Here is how I would choose:

Situation	CRF	What to expect
Archiving a clip you may edit again	16 to 18	Very hard to tell from the source, larger file
Sharing a copy that must look right	20 to 21	Differences only visible when you hunt for them. This is what the converter uses
Sending in a chat app or email	23 to 28	Visible softening on fine texture, much smaller

The preset is the other half. A slower preset spends more encoding time to reach the same quality in a smaller file. VidClip uses veryfast because the encode runs on your own processor in a browser tab, and a slow preset on a long 4K clip would take far longer than most people want to wait. If you have a desktop FFmpeg and a lot of footage, -preset slow buys a smaller file for the same look.

For HEVC to H.264 specifically, one more rule: do not pick your CRF to match the original's file size. The two codecs use bits differently, so matching size means accepting visible loss. Pick the quality you want and accept the size.

How do you convert without uploading?

Most pages in this space take the file to a server: you upload, wait in a queue, and download the result. That works, but it means your personal clips sit on someone else's machine for a while, and a phone video is often exactly the kind of file you would rather not send anywhere.

The video to MP4 converter here does the work locally. The page loads FFmpeg compiled to WebAssembly, reads the file from your disk into the tab's memory, converts it on your own CPU, and hands the result back. The server only serves the page. Output is H.264 video with AAC audio in an MP4, which is the combination that opens on nearly everything.

Steps:

1. Open the converter and drop in the HEVC file (MOV from an iPhone, or MP4 or MKV from an Android or camera).
2. Run the conversion. Short clips finish quickly. Long or 4K clips take real time, because the work happens on your machine in one thread, so convert the clips you need rather than a whole camera roll.
3. Download the MP4 and open it on the device that was giving you trouble.

You should know the limits of the free version: input files up to 200 MB, and a small corner mark on video exports. Pro lifts both. If the clip is bigger than the cap, trim it first or split it into parts.

If you would rather use a desktop tool, the plain FFmpeg command for a standard-range clip is:

ffmpeg -i input.mov -c:v libx264 -preset slow -crf 20 -pix_fmt yuv420p -c:a aac -b:a 128k -movflags +faststart output.mp4

Each part has a job: libx264 selects the H.264 encoder, -crf 20 sets the quality, -pix_fmt yuv420p forces the 8-bit format almost every player accepts, -c:a aac re-encodes the audio to a universal format, and -movflags +faststart moves the index to the front so the file starts playing before it finishes loading. Do not add -c copy: that skips the re-encode, so the HEVC stays HEVC.

Frequently asked questions

Does converting H.265 to H.264 lose quality?

Yes, in the strict sense, because H.264 has to compress the picture again and always discards some detail. At a high-quality setting (CRF 18 to 21) the difference is generally hard to see in normal viewing, and it is smaller than the loss you take from sending a clip through most chat apps. Keep the HEVC original, and convert from it once.

Why is my converted video larger than the original?

HEVC reaches similar quality at a lower bitrate than H.264, and phones record at a fairly efficient setting. A constant-quality H.264 encode spends the bits it needs to look good, so the file grows. In my test the standard-range clip grew by about 63% and the HDR clip by about 78%, but that was a noisy synthetic clip, so your ratio will differ. A higher CRF number shrinks it at the cost of detail.

Why do my converted HDR videos look washed out?

Phone HDR footage is 10-bit with a BT.2020 colour gamut and an HLG or PQ brightness curve. A plain conversion to 8-bit H.264 keeps those tags but does not remap the brightness. Players that read the tags display it correctly, and players that ignore them show it flat and grey. Either turn HDR off on the phone for future clips, or tone map the clip to standard range on the desktop with the FFmpeg command above. This site's converter does not tone map.

Can I convert HEVC on Windows without the codec extension?

Yes. The conversion tools described here carry their own decoder, so they do not depend on Windows having an HEVC decoder installed. FFmpeg decodes HEVC itself, in the desktop build and in the browser build. That is also why an H.264 copy plays in apps where the original does not: it moves the problem from the viewer's computer to the file. Apple documents the format choice on the phone side: in Settings, Camera, Formats, picking Most Compatible makes new videos use H.264, as described in Apple's guide to HEIF and HEVC media.