Open a .mov file and a .mp4 file with the same content in a hex editor and you'll find they're almost identical - the same box structure, the same H.264 or HEVC video bytes, the same AAC audio bytes, differing only in the ftyp brand code at the very start of the file and a few bookkeeping atom names. The two formats are genuinely siblings, not distant cousins. Yet they behave differently at the point of playback and upload in ways that trip up millions of people every year.

#The short version

MOV is Apple's QuickTime File Format, published in 1991. MP4 is the ISO Base Media File Format, standardized in 2001, using QuickTime as the direct blueprint. The two containers share the same atom structure, the same track layout, the same seek-index conventions. On the same H.264 + AAC bytes, converting between them is a header rewrite of a few dozen bytes at most. But Apple never released MOV as an open standard, so ecosystems that predated the Apple partnership (Windows, Linux, most Android manufacturers) built their video decoders against MP4 and refused MOV by default. Twenty-five years later that split is still visible everywhere.

#Where they actually differ

The ftyp atom

The first four-character code inside the ftyp atom at the start of the file identifies the format lineage. MOV files start with qt   (with trailing spaces); MP4 files start with isom, mp42, mp41, or iso5 depending on the encoder. This is the single most-important byte-level difference between the two: playback code inspects the ftyp brand and takes different parsing paths for each. Windows Media Foundation refuses to parse any ftyp starting with qt  ; it happily parses any file starting with isom or a specific MP4 brand.

Extended atoms

QuickTime added some atoms MP4 never adopted: timecode tracks (used by pro editors for reference to source timecode), chapter thumbnails (little JPEG per chapter shown in QuickTime Player's scrubber), reference movies (a MOV that points at multiple actual video files), and various QuickTime-specific text tracks. Modern iPhone MOVs, macOS Screen Recording MOVs, and QuickTime Player exports rarely use these - they're holdovers from pro workflows. On a normal MOV file the only difference from MP4 is the ftyp brand.

ProRes

Apple ProRes is a codec that lives inside MOV. MP4 technically accepts ProRes on paper (it's in the codec registry) but no consumer player decodes ProRes-in-MP4; Apple's ecosystem expects ProRes-in-MOV. Converting a ProRes MOV to MP4 either requires a real re-encode to H.264 (Wave's default for ProRes to MP4) or produces a nominally-valid MP4 that nothing plays. This is the one codec case where MOV genuinely holds something MP4 can't practically hold.

Where it matters

Same bytes, different playback surface

MOV Apple ecosystem, and mostly nowhere else
  • Plays: iOS, macOS, QuickTime Player, VLC
  • Refuses: Windows Media Player, Films & TV, Discord embeds, most smart TVs
  • iPhone records MOV by default
  • macOS Screen Recording saves MOV by default
  • QuickTime Player exports MOV by default
vs
MP4 Everywhere
  • Plays: iOS, macOS, Windows, Android, all browsers, smart TVs, chat apps
  • Refuses: nothing significant
  • Camera default on most Android phones
  • OBS optional output
  • Standard delivery format for every upload pipeline
Same underlying codec, same underlying container structure. The playback surface still diverges - because Apple never gave the world permission to parse QuickTime's ftyp brand.

#When you need to convert

  • Sending an iPhone or Mac recording to a Windows user. Windows Media Player refuses .mov; the recipient gets "can't play this file" and has to install VLC. Converting to MP4 fixes it in seconds - the operation is a container swap, not a re-encode.
  • Uploading to a service that pattern-matches on extension. Some CMSes, LinkedIn video posts, WhatsApp Web, and older Instagram upload flows reject .mov based on extension alone even when the file would play fine renamed to .mp4. Converting properly (Wave rewrites the ftyp brand, not just the extension) makes the file compliant.
  • Chat client inline previews. Discord's embedded video player sometimes shows a thumbnail-less "download to view" state for .mov files; Slack does the same. MP4 files preview inline.
  • Chromecast, some smart TVs, some in-flight entertainment systems. All check the ftyp brand and refuse MOV.

#When you can keep MOV

When the file stays inside Apple's ecosystem. Editing in Final Cut, iMovie, or Motion natively supports .mov as the working format. Sharing via AirDrop between Macs and iPhones preserves quality without needing a conversion. Uploading to iCloud Photos or Apple TV's Home Sharing works with .mov. If the destination is Apple, MOV is fine; if it leaves Apple, convert.

#Why the conversion doesn't lose quality

On any modern MOV containing H.264 or HEVC + AAC (which is what iPhones, screen recordings, and QuickTime Player produce), the MP4 conversion is a container swap. Wave rewrites the ftyp brand, moves the moov atom to the front for fast-start playback, and copies the video and audio streams through untouched. Every H.264 frame and every AAC sample reaches the output identical to the source. The file size is essentially unchanged (within a few kilobytes of the input); the quality is bit-for-bit identical.

The one MOV case that requires a real re-encode is ProRes - see ProRes to MP4 for the specifics of that path. For iPhone recordings, screen recordings, and everyday QuickTime output, the swap is instant and lossless.

#The takeaway

MP4 vs MOV is a compatibility question dressed up as a format question. The two containers share the same underlying spec; the difference is which one Windows and non-Apple players agreed to parse. On modern content (H.264 or HEVC + AAC), converting between them is a header rewrite - not a re-encode - and takes seconds regardless of file size. If your file needs to leave the Apple ecosystem, use MOV to MP4 or the branded intent pages (iPhone screen recording, Mac screen recording, QuickTime) and the same file plays everywhere.