How to Convert HEVC (H.265) to MP4 (H.264)

The first thing to understand is that HEVC, also called H.265, is a video codec, not a file wrapper. An MP4 is a container that can hold many different codecs, including H.265 itself. So "convert HEVC to MP4" almost never means changing the video into something new. It usually means taking an H.265 stream, which might be sitting in a raw .hevc file or already inside a .mov or .mkv, and placing it into an MP4 wrapper.

That distinction decides everything about how fast the conversion is and whether you lose any quality. There are two genuinely different operations hiding behind the same request, and picking the right one saves you both time and image quality. This guide explains what HEVC really is, what happens inside each path, and how to choose between them for any given clip.

HEVC is a codec, MP4 is a container

A container is like a box, and the codec is how the video inside was compressed. MP4, standardized as ISO/IEC 14496-14, is a wrapper built on the ISO base media file format that can carry many codecs and is happy to hold H.265 video.^[4] So if your only goal is to get an .mp4 file that holds your HEVC footage, no re-encoding is needed at all. The compressed video data is copied across untouched, byte for byte, and only the wrapper around it changes. This is called a remux, or a stream copy, and it finishes in seconds with zero quality loss.

The complication is playback. Many older players, web browsers, and editing programs cannot decode H.265. So people who say they need "HEVC to MP4" often really need the video to be readable on a device that chokes on H.265. In that case a container swap will not help, because the video inside is still H.265. You have to actually re-encode it to a more widely supported codec, and that is a slower, lossy operation.

What HEVC actually is

HEVC stands for High Efficiency Video Coding, and it is jointly published as ITU-T Recommendation H.265 and as ISO/IEC 23008-2, the two names referring to the same technical standard.^[1] It was finalized in 2013 as the successor to H.264 (AVC), and its headline achievement is roughly twice the compression efficiency: it can deliver the same visual quality at about half the bitrate, or better quality at the same bitrate.^[2] That efficiency is exactly why iPhones and modern cameras adopted it, and why your HEVC files are so pleasingly small.

It achieves this with larger, more flexible coding blocks than H.264, more sophisticated motion prediction, and better entropy coding. Where H.264 divides a frame into fixed sixteen-by-sixteen macroblocks, HEVC uses coding tree units that can span up to sixty-four-by-sixty-four pixels and subdivide adaptively, so flat regions are described with far fewer bits and detailed regions get the fine partitioning they need. Combined with thirty-five intra-prediction directions and stronger context-adaptive binary arithmetic coding, this is what produces the roughly halved bitrate. The catch is that all of that extra cleverness demands more decoding work and, historically, involved patent licensing that slowed universal adoption. That is the root of the compatibility problem: HEVC is technically superior but not as widely decodable as the older H.264, which is why "make it play everywhere" so often means "get it off HEVC."

Inside an MP4: boxes, tracks, and the hvc1 stream

To see why a container swap can be instant, it helps to know what an MP4 actually is on disk. MP4 is built on the ISO base media file format and stores everything as a tree of nested boxes (also called atoms), each with a size and a four-character type.^[4] A moov box holds the metadata: how many tracks there are, their timescales, codec descriptions, and an index of where each frame lives. A separate mdat box holds the actual compressed media bytes. Crucially, the compressed H.265 frames sitting in mdat are the same bytes whether they came from a MOV, an MKV, or a raw stream. The container is just the bookkeeping wrapped around them.

When HEVC lives inside MP4, its track is tagged with a sample-entry code, usually hvc1 or hev1, and the sequence and picture parameter sets that a decoder needs are recorded in the track's codec configuration.^[3] A remux rebuilds only the moov index and rewraps the existing mdat bytes into MP4's box layout. Nothing in the picture data is touched, which is exactly why it finishes at the speed of a file copy and loses no quality. Understanding this box model also explains a subtle failure some people hit: if the source stores parameter sets in an unusual place, a lazy remux can produce an MP4 that technically holds valid H.265 but that some players stumble on, which is one of the few reasons a remux occasionally needs a re-encode fallback.

Two ways to convert, and how to choose

Path one is the remux. You keep the H.265 video exactly as it is and just rewrap it as MP4. The file stays small because H.265 is very efficient, and there is no generation loss because nothing is re-compressed. The trade-off is that the result still requires H.265 support to play.

Path two is the re-encode to H.264. Here every frame is decoded and compressed again using the older, more universal H.264 codec. The upside is that almost every phone, browser, TV, and editor made in the last decade can play H.264 without special support. The downsides are real: H.264 is less efficient than H.265, so the file gets noticeably larger at the same visual quality, and re-encoding always throws away a little detail. Choose this path only when compatibility matters more than file size.

What happens inside a remux versus a re-encode

The two paths do genuinely different amounts of work, which is why one is instant and the other is slow. A remux touches only the container. The tool reads the boxes of the source file, extracts the already-compressed H.265 elementary stream along with its timing and audio, and writes those same compressed bytes into MP4's box structure.^[3] Not one video frame is decoded or re-compressed, so there is nothing for quality to lose and no heavy computation, which is why it completes almost as fast as copying the file.

A re-encode is a full round trip. Every frame of H.265 is decoded back to raw pixels, then handed to an H.264 encoder that compresses it again from scratch, making new prediction and quantization decisions frame by frame. This is computationally expensive, so it takes minutes rather than seconds, and because H.264 will discard some detail during that fresh compression, the result is very slightly softer than the source. The audio is usually copied through untouched even during a video re-encode, since the compatibility problem is almost always the video codec, not the sound.

The re-encode settings that shape the result

If you do take the re-encode path, a few parameters decide whether you get a clean, compatible file or a bloated, soft one. Unlike a remux, which has nothing to tune, an H.264 re-encode is a genuine compression job with real levers.

The single most important choice is constant rate factor encoding rather than a fixed bitrate. CRF lets the encoder spend bits where the picture needs them and save bits on simple frames, which gives a more consistent look than forcing every second to the same size. A CRF around 20 is a good starting point: low enough that the H.264 output looks essentially identical to the H.265 source, high enough that the file does not balloon. Because H.264 is inherently less efficient than H.265, expect the re-encoded MP4 to be noticeably larger than the original even at matched visual quality, which is the unavoidable cost of trading the newer codec for universal playback.

Convert HEVC to MP4, step by step

1. Open the converter and add your file

   Open the FileFormer video converter and add your HEVC source, whether it is a raw .hevc stream or an H.265 clip already inside a .mov or .mkv. It runs on your device, so nothing is uploaded.

2. Decide whether you need a remux or a re-encode

   If the devices you care about can play H.265, choose a plain container swap to keep the file small and lossless. If you have hit a player that refuses to open the file, plan to re-encode the video to H.264 instead.

3. Set MP4 as the output

   Select MP4. For the remux path the H.265 stream is copied straight through. For the compatibility path, set the video codec to H.264 so every frame is rebuilt in the more widely supported format.

4. Convert and check playback

   Run it and download the MP4, then open it on the device that matters. If it plays, you are done. If it still refuses, you were on the remux path and need to re-run with H.264 re-encoding.

Remux versus re-encode at a glance

Real-world scenarios and the right path

The right choice comes down to where the video has to play and how much you care about size. A few common cases:

The rule of thumb is to remux whenever the destination can decode H.265, because it is free and lossless, and to re-encode only when you actually hit a wall of incompatibility.

Common mistakes and quality traps

Most trouble with HEVC-to-MP4 comes from misreading which operation is actually needed. Keeping these traps in mind saves both time and image quality.

Re-encoding when a remux would do. The most common waste is running a full H.264 re-encode to "convert to MP4" when every device in play already decodes H.265. That throws away detail and inflates the file for no benefit. Always attempt the remux first and only fall back to re-encoding if a real player rejects the result.

Encoding to H.264 and then back to H.265 later. Each lossy pass compounds. If you re-encode an iPhone clip to H.264 for a website today and someone later re-encodes that H.264 file back to H.265 for storage, you have stacked two generations of loss on top of the original capture. Keep the untouched source and derive throwaway copies from it rather than chaining conversions.

Forgetting the audio and metadata. A video-only re-encode should still carry the audio track and, ideally, rotation and timing metadata. A converter that copies the AAC audio straight through avoids a needless second lossy audio pass, and preserving the rotation flag keeps vertical phone footage from playing sideways. Confirm the sound and orientation survived before you delete the source.