Quick Answer: To convert a QuickTime .mov file to MP4 without uploading it anywhere, open Clipy's free MOV-to-MP4 converter, drop the .mov in, and click download. Conversion runs locally in your browser via FFmpeg compiled to WebAssembly. For most QuickTime recordings the streams are stream-copied (no re-encode), so the result is bit-for-bit identical in quality. No upload, no signup, no watermark, files up to about 500 MB.

If you have ever recorded your screen on a Mac with QuickTime and then tried to send the file to a Windows colleague, drop it into a Notion page, upload it to a CMS, or attach it to a PowerPoint slide, you have probably hit the same wall: the player politely refuses, or the embed silently fails, or the upload form rejects the file. The video itself is fine. The problem is the container label on the file — .mov versus .mp4 — and the cure is almost always a remux, not a re-encode.

This guide walks through what actually changes when you "convert" a .mov to .mp4, why the conversion is usually instant and lossless, when it is not, and how to do it in your browser without ever uploading the file. We will use Clipy's free MOV-to-MP4 tool throughout because it matches the privacy posture this article recommends — local conversion via FFmpeg WASM, no server upload, no account.

Why convert QuickTime .mov to MP4 at all?

A modern QuickTime screen recording on macOS is, internally, almost the same file as an MP4. Both .mov and .mp4 are containers built on top of the ISO Base Media File Format — the "atoms" specification Apple originally authored for QuickTime and that ISO later standardized as MP4. The codecs inside are usually H.264 video plus AAC audio, which is also the most common pairing inside MP4. So the bytes that hold your actual picture and sound are identical in both formats. The only thing that differs is the wrapper.

That sameness is also the joke of MOV-to-MP4 conversion: in most cases there is nothing to "convert." The conversion exists entirely because a lot of software was written to look at the file extension or the MIME type and refuse anything that isn't .mp4. Real-world places this happens:

  • A Windows coworker's default video player will not open .mov without QuickTime for Windows, which Apple discontinued years ago.
  • A CMS that accepts video uploads only allows .mp4, .webm, or .mkv.
  • PowerPoint refuses an embedded .mov on Windows, even though the same file plays in PowerPoint on Mac.
  • Notion, Slack, and many learning-management systems will accept the upload but the inline player silently fails.
  • A video-editing pipeline downstream of yours expects MP4, full stop.

None of those are quality complaints. They are container-label complaints. Which is why the conversion you usually want is the cheapest possible one — keep the video and audio streams exactly as they are, swap the wrapper, ship the result.

How do I convert MOV to MP4 without uploading the file?

The browser-based path is the shortest one and, importantly, the only one that lets you keep the file on your own machine while you do it. Here is the full flow with Clipy's MOV-to-MP4 converter:

  1. Open the tool page. Go to clipy.online/tools/mov-to-mp4 in any modern browser — Chrome, Edge, Safari 14.1+, or Firefox. The page loads the FFmpeg WebAssembly bundle in the background while you read.
  2. Drop your .mov file onto the upload zone. You can also click the zone to pick a file from disk. The picker accepts .mov including QuickTime screen recordings; the file size limit is roughly 500 MB in the browser. Nothing leaves your device at this point — the file is read into the page's own memory, not posted to a server.
  3. Wait for the conversion. For a typical QuickTime H.264 + AAC recording the tool detects that a stream-copy is possible and just rewrites the container. This is usually fast — often a small fraction of the playback duration of the video. If your file uses ProRes or HEVC the tool will fall back to a full transcode, which is slower but still local.
  4. Click download. You get a .mp4 with the same name as your input. Done. You can verify nothing was uploaded by opening your browser's network tab during the conversion — there are no outgoing requests with your file as the payload.

If you want the same flow without the browser at all — for files larger than 500 MB or for batch conversion — the Clipy desktop app has a native version of this conversion that runs faster and handles bigger files. But for one-offs, the browser tool is the right default.

How does in-browser MOV conversion actually work?

The Clipy MOV-to-MP4 converter runs FFmpeg compiled to WebAssembly inside the browser tab. WebAssembly is a low-level bytecode format that browsers can run at near-native speed; FFmpeg, the reference open-source video toolkit, has been ported to it so that everything FFmpeg can normally do on a desktop also works inside a web page. There is no server in the loop and no proprietary encoder — the same code that runs on a Linux box at the command line is running inside your tab.

The interesting part is what FFmpeg actually does for you when the input is a QuickTime recording. There are two paths it can take:

  • Stream-copy (remux). When the video stream is already H.264 and the audio stream is AAC — which is the default for QuickTime screen recordings on every modern Mac — FFmpeg can copy the bytes of those streams directly into a new MP4 wrapper without re-encoding. The result is bit-for-bit identical to the input on the picture and sound side. Only the container's atoms change. This is the fast path and the lossless path. The tool defaults to AAC re-encoding for audio at a high bit-rate to maximize compatibility (some old MOVs use Apple-only audio codecs that confuse non-Apple players), so audio is perceptually lossless rather than bit-identical.
  • Transcode. If the video stream is something MP4 cannot legally carry — ProRes is the common case, and some HEVC variants in older recordings are too — FFmpeg has to decode and re-encode. That takes longer and is mildly lossy. The tool will still produce a working MP4, but the result will be smaller, slightly softer, and slower to produce than a remux.

The default behavior for the browser tool is stream-copy when possible, which is the right call for the 90%+ case of "I made a QuickTime screen recording and I need it in MP4." If you are doing color-managed editorial work and your input is a 10-bit ProRes master, you should not be using a browser tool to push it into H.264 — that is a real transcode and it deserves a real desktop encoder.

Will the converted MP4 lose quality?

Almost never, when you start from a typical QuickTime screen recording. Here is the precise breakdown:

  • Video. Stream-copied. The encoded H.264 frames are written into the new container untouched. There is no quantization step, no re-encode, no "compression on top of compression." A frame-by-frame pixel diff between the source and the output would show identical pixels.
  • Audio. Re-encoded to AAC at 192 kbps by default. This is perceptually transparent at any reasonable source bit-rate, but it is technically a re-encode rather than a copy. The reason for the re-encode is that some old QuickTime files ship with audio codecs (Apple Lossless, older ALAC variants, occasional QDM2) that some non-Apple MP4 players will not accept. Re-encoding to AAC removes that risk.
  • Metadata. Most of the useful metadata (duration, frame rate, sample rate, color tags) is preserved. QuickTime-specific atoms that have no MP4 equivalent are dropped. This usually doesn't matter, but if you depend on QuickTime time-code metadata for an editorial workflow, that is one thing the conversion will not carry across.

The one quality scenario where you should care is when the input is a very high-bit-rate ProRes or HEVC master and you are forced into a transcode. In that case the visible loss depends on the encoder settings. Browser-based FFmpeg encodes are competent but not tuned for archival masters. For that, use a desktop encoder; for everything else, the in-browser remux is the right tool.

How do I convert MP4 back to MOV, or to GIF?

Sometimes the round trip is the goal — you have an MP4 from someone else and you need to drop it into a Final Cut project that is happier with .mov, or you want a Slack-friendly GIF preview of a 10-second clip from a recording. Clipy has dedicated single-purpose tools for each direction:

  • MOV → MP4 — the tool described in this article.
  • WebM → MP4 — for WebM files (common output of in-browser screen recorders) that you need in MP4 for compatibility.
  • AVI → MP4 — for old AVI files (DivX, Xvid, MP3 audio inside) that you want modernized.
  • MP4 → GIF — for short, looping previews suitable for Slack, GitHub PRs, and email.
  • Video Compressor — when the file plays everywhere but is too big to attach.

All of them run in the browser via the same FFmpeg WebAssembly engine, with the same privacy posture: nothing uploads, no signup, no watermark. If your day involves "send a recording to a coworker" more than once a week, it is worth bookmarking the tools index at clipy.online/tools.

Why does my .mov still fail to play after I rename it to .mp4?

This trips people up often enough to deserve its own section. Renaming the file extension from .mov to .mp4 in Finder or File Explorer does not actually convert anything — it just changes the label on the file. The byte structure inside is still a QuickTime container with QuickTime atoms, and a strict MP4 player will read the first few bytes, see that the container's magic number says it is a QuickTime file, and refuse to play it (or play it incorrectly). The same is true in reverse: a video editor that sniffs the file's actual contents instead of trusting the extension will see through the rename immediately.

A real conversion writes a new file with proper MP4 atoms in the right order. That is what FFmpeg's remux does, that is what HandBrake and QuickTime Export do, and that is what the browser tool does. If renaming "worked" for you in the past, it was because the player you tried it with was lenient and looked at the actual bytes rather than the extension — many do, but not all, which is why the rename trick is unreliable.

A related sub-case is the moov atom location. Some MOV recordings put the index (the moov atom) at the end of the file, which is fine for local playback but breaks streaming because the player needs the index up front. Most modern conversions to MP4, including the browser tool, perform a +faststart step that moves the moov atom to the front of the file. The result is an MP4 you can stream from a server or a CDN without the player having to download the whole thing first. If a converted MP4 "plays locally but not when uploaded," the moov atom location is the first thing to check.

Is this better than HandBrake or QuickTime export?

Different tools are right for different jobs, but the comparison is worth being concrete about because "just use HandBrake" gets thrown around as if it's the only answer.

HandBrake. HandBrake is excellent at transcoding — that is its core competence. By default it re-encodes the video stream, which is the wrong choice when your .mov is already H.264 and you only need a new container. HandBrake can be configured to do a remux via the "Pass-through" video setting, but that is several clicks deep and most users never find it. For the typical "my QuickTime recording will not play on Windows" case, HandBrake is overkill and will produce a smaller, lossier MP4 in five times the time of a remux. For genuine transcodes — "I have a 4K ProRes master and I need a streaming-friendly H.264 MP4" — HandBrake is great.

QuickTime Player export. File → Export As in QuickTime is convenient on a Mac but only offers a small set of canned presets. The presets always re-encode. So you trade upload-free convenience for a slow, mildly lossy export to settings you didn't pick. Fine for one-offs, less fine for any regularity.

FFmpeg on the command line. The fastest path of all if you already have FFmpeg installed: ffmpeg -i input.mov -c copy output.mp4. That is precisely what the browser tool runs internally for the common case. The browser version exists for the same reason browser screen recorders exist — most people who need to do this once a month are not going to install FFmpeg.

The browser tool. Best fit when you want a one-step conversion, you want to keep the file local, you don't want to install anything, and the file is under about 500 MB. Worst fit for very large files or for archival-quality transcodes; use the Clipy desktop app or a real local FFmpeg pipeline for those.

If QuickTime is causing this problem, should I stop using QuickTime?

This is actually the right question to ask if MOV-to-MP4 conversion is on your weekly chore list. QuickTime Player's screen recording is fine for a private archive on your Mac, but it has a couple of opinionated defaults that conflict with how most people actually use a screen recording in 2026:

  • It records to .mov by default, even though almost every place you'll send the result wants .mp4.
  • It records to a local file, even though almost every place you'll send the result is a link in Slack or email.
  • Audio capture from system audio still requires a third-party kernel extension or virtual audio device on most macOS versions, which is a friction wall most people don't want to climb.
  • The export step is a separate, slower workflow.

If your end goal after a screen recording is "send a link my coworker can watch right now," the conversion step is just rework. Clipy's screen recorder records directly to a streaming-friendly format and gives you a shareable link the moment you stop — no MOV in between, no MP4 conversion afterward, no email attachment. The full how-to lives in the Clipy how-to guide and the platform-specific versions are at clipy-for-mac and clipy-for-windows.

If you specifically want the QuickTime aesthetic — local file first, share later — but want it to come out as MP4 in the first place, the desktop app records to MP4 natively on both macOS and Windows. Either way, the goal is to remove the conversion step from your loop, not just to make it faster.

Is this tool actually private — can I verify nothing uploads?

Yes, and the verification is something you can do yourself in about thirty seconds. The Clipy MOV-to-MP4 converter loads its FFmpeg WebAssembly bundle when the page opens; once that is done, the conversion happens entirely inside your browser tab. The file you drop in is read by JavaScript into memory, handed to FFmpeg WASM, and the resulting MP4 is offered back to you as a regular browser download.

To verify:

  1. Open the page in Chrome or Edge.
  2. Open DevTools (F12 or Cmd+Option+I), Network tab, then check "Preserve log."
  3. Drop your .mov file in and let the conversion finish.
  4. Sort the request log by size. The biggest requests will be the FFmpeg WebAssembly assets that loaded with the page; you will not see an outbound request whose body is anywhere near the size of your input file.

You can also disconnect from the network after the page has loaded and the conversion will still run. The tool page documents this — "works offline once the page is loaded" — and you can confirm it the same way: load the page, kill your wifi, drop in a file, watch it convert. The privacy posture is not a marketing claim; it is a property of where the code runs.

Common questions about converting MOV to MP4

The questions we hear most often, with short answers.

Will my .mov lose quality after converting to .mp4? Almost never. The video stream is stream-copied, meaning the encoded bytes are not re-encoded; only the container is rewritten. Audio is re-encoded to AAC at a high bit-rate for compatibility, which is perceptually lossless from any reasonable source.

Is the .mov uploaded somewhere? No. The conversion runs entirely in your browser via FFmpeg compiled to WebAssembly. The file never reaches Clipy's servers, the CDN, or any third party. You can verify this in the Network tab of your browser's developer tools.

What is the maximum file size? About 500 MB in the browser. For longer screen recordings or 4K source footage, use a desktop converter — the Clipy desktop app handles bigger files natively.

What about ProRes or HEVC .mov files? ProRes inside MP4 is awkward and many players will refuse it; for ProRes you usually want a real transcode in HandBrake, FFmpeg, or the Clipy desktop app rather than a browser remux. HEVC usually works but compatibility is patchier than H.264.

Why is this faster than HandBrake? Because for typical QuickTime input it does not transcode. HandBrake re-encodes by default, which is overkill if your .mov is already H.264 + AAC. The browser tool detects that case and just remuxes — typically an order of magnitude faster.

Does it work offline? Yes, once the page has loaded. The FFmpeg WebAssembly engine and the conversion logic are entirely client-side, so you can disconnect from the network after the page loads and conversions will still run.

Can I convert MP4 back to MOV? The tool is one-directional. For the reverse direction, FFmpeg on the command line — ffmpeg -i input.mp4 -c copy output.mov — does the equivalent remux in the other direction. We do not currently ship an MP4-to-MOV browser tool because the demand is much smaller than the demand in the other direction.

The takeaway

MOV-to-MP4 conversion is, for the vast majority of QuickTime screen recordings, a container swap rather than a re-encode. That is why an in-browser tool can do it instantly and losslessly — there is genuinely nothing to compute, just a wrapper to rewrite. The Clipy MOV-to-MP4 converter ships exactly that flow, runs locally on your device via FFmpeg WebAssembly, and skips every wall — no upload, no signup, no watermark, no usage cap.

If MOV-to-MP4 is a recurring chore in your week, the bigger win is to stop producing MOVs in the first place. Record with Clipy in your browser or with the desktop app and you get a streaming-ready file plus a shareable link the moment you stop — no conversion step, no email attachment, no "please install QuickTime for Windows" reply. For everything else, bookmark the tools index; the WebM, AVI, and GIF converters all use the same engine and the same privacy posture as the MOV converter described here.