The first time I converted a screen recording for a client, I did it the way everyone does: dropped the MOV into a converter, waited eleven minutes, and sent the MP4. The file was 40% smaller and noticeably softer, and the client asked why the text in the demo looked fuzzy. The answer was that nothing needed converting in the first place. The video inside that MOV was already H.264, which is exactly what an MP4 holds. Eleven minutes of re-encoding had thrown away quality to produce a file that could have been byte-identical in about two seconds. That is the whole idea behind the video converter on toolz.dev, and it is worth understanding whichever tool you use.
TL;DR: Most MOV files already contain H.264 video and AAC audio, which is the same thing an MP4 contains, so converting between them does not require re-encoding at all. The streams are copied into a new container, a process called remuxing. It takes seconds instead of minutes and loses nothing, because no pixel is decoded or re-compressed. The Toolz video converter copies by default and only re-encodes when the formats genuinely require it, and it runs through ffmpeg compiled to WebAssembly inside your browser tab, so the video is never uploaded.
What is a container, and why does it matter?
A video file has two layers, and almost every confusing thing about video conversion comes from mixing them up.
The container is the wrapper. It holds the streams, records how long they are, where each frame starts, what language the audio track is in, and which thumbnail to show. MP4, MOV, WebM, AVI and MKV are containers. The extension on the file names the container, not the video.
The codec is the compression inside. H.264, H.265, VP9 and AV1 compress the picture. AAC, Opus, MP3 and FLAC compress the sound. The codec is what determines whether the file plays on a given device, and it is what takes time to change.
Once you separate those two ideas, the useful question stops being "what format is this?" and becomes "which layer am I changing?" Changing the container is cheap. Changing the codec is expensive and lossy. A tool that does not distinguish between them will charge you the expensive operation for the cheap job every single time.
Why is MOV to MP4 nearly instant?
Because a MOV and an MP4 are close relatives. QuickTime's file format was the basis for the ISO Base Media File Format, which MP4 is built on, so the two containers organise their data in nearly the same way. And the streams inside them are usually the same streams: an iPhone recording, a Mac screen capture, a DSLR clip and a Premiere export all typically produce H.264 video with AAC audio, whether they wrap it in a .mov or a .mp4.
So the conversion is a remux: read where each stream begins and ends, write those bytes into a new container, write a new index. No frame is decoded. No pixel is examined. The output is the same video data in a different wrapper, and it is lossless in the strict sense that the decoded frames are bit-for-bit identical.
In practice that means a two-minute clip finishes in about a second instead of a minute or more, and the file size barely moves, because the video data did not change. A converter that takes minutes on this job and hands back a smaller file has re-encoded it, and the size drop is quality you no longer have.
Here is when each path applies.
| Source | Target | What happens | Speed | Quality cost |
|---|---|---|---|---|
| MOV (H.264/AAC) | MP4 | Remux, streams copied | Seconds | None |
| MP4 (H.264/AAC) | MOV | Remux, streams copied | Seconds | None |
| MOV or MP4 | WebM | Re-encode to VP9/Opus | Minutes | Some, depends on settings |
| Any video | GIF | Re-encode, palette reduced to 256 colours | Minutes | Severe, by design |
| GIF | MP4 | Re-encode to H.264 | Seconds to a minute | Minor, usually invisible |
When do you have to re-encode?
Three cases, and only three.
The target container cannot hold the codec. WebM accepts VP8, VP9 and AV1 for video and Vorbis or Opus for audio. It does not accept H.264. So MP4 to WebM is always a real conversion, and it will take real time.
The source codec is not H.264 in an H.264 wrapper. A ProRes MOV from a camera, a DV capture, an old DivX AVI: those hold codecs that MP4 can technically carry in some cases but most players will refuse. Converting them means decoding and re-compressing.
You are deliberately changing the picture. Lowering the resolution, dropping the bitrate, changing the frame rate. There is no way to make a video smaller without re-compressing it, which is why shrinking a file is a different job from changing its format. For that, use the video compressor, which exists precisely because compression and conversion are different operations that people reasonably confuse.
Why is converting to GIF so much worse than it sounds?
A GIF holds at most 256 colours for the entire image. That is the format's defining limit, set in the GIF89a specification in 1989, and no encoder can work around it. Every conversion from video to GIF therefore has to choose which 256 colours out of the 16.7 million the source may contain.
Done naively, frame by frame, each frame picks its own best 256. The result is that the same shirt is a slightly different colour in consecutive frames, and the whole picture appears to crawl and shimmer. This is the single most common complaint about video-to-GIF output, and it is entirely an artefact of per-frame palettes.
The fix is a two-pass encode: scan the whole clip first, build one palette that serves all of it, then encode every frame against that shared palette. The crawl disappears because the colours stop moving. The Toolz converter runs both passes, which is why a GIF from it takes a moment longer than a single-pass tool and looks considerably steadier.
The second surprise is size. GIF stores whole frames rather than the differences between them, with none of the motion compensation that makes modern video codecs efficient. A five-second clip that is 400 KB as an MP4 will routinely be 4 MB as a GIF. Which leads to the conversion worth doing more often than people realise.
Should I convert a GIF to MP4 instead?
Almost always, yes. The same animation encoded as H.264 is typically a tenth of the size, plays inline on mobile browsers where a large GIF stalls or is throttled, and supports hardware decoding so it does not heat the phone. Every major social platform quietly converts the GIFs you upload into video for exactly these reasons, which is a reasonable signal about which format suits the job.
One detail decides whether the conversion works at all. H.264 requires even pixel dimensions, because of how the standard organises chroma sampling, and GIFs frequently have odd ones: a 601-pixel-wide GIF is perfectly normal. An encoder handed odd dimensions either fails outright with a cryptic message or silently pads the frame. The converter here rounds the size down to the nearest even number before encoding, which is a one-pixel crop nobody can see and the difference between a file and an error.
Does the video get uploaded anywhere?
No, and this is the part that changes how you can use it. The conversion runs through ffmpeg compiled to WebAssembly, executing inside your browser tab. The file is read from your disk into page memory, converted there, and handed back as a download.
That has three practical consequences:
- Nothing leaves your machine. Open devtools, switch to the network panel, convert a file, and watch: no request carries the video. For footage under NDA, unreleased product demos, anything with a person in it who did not consent to a third-party upload, this is the difference between usable and not.
- There is no queue and no size cap. You are not waiting behind other people's jobs, and no plan limits you to 100 MB. The real limit is your browser tab's memory, which on a normal laptop handles files of a few hundred megabytes comfortably.
- The first run is slower than the rest. The ffmpeg WebAssembly bundle has to download once, which is a few seconds. After that it is cached, and subsequent conversions start immediately.
The trade is honest: a server with a dedicated encoder is faster on very large files. For the clips most people convert, the round trip of uploading and downloading costs more time than the encode saves.
Which settings make a difference?
For a remux, none. There is nothing to configure, because nothing is being re-decided.
For a re-encode, two.
Resolution does more than any other setting. Halving the width and height quarters the pixel count, and the file roughly follows. Going from 1080p to 720p is the single most effective change available, and on a phone screen the difference is hard to see.
Bitrate or quality target is the other. Most tools expose this as a quality slider rather than a number, which is the right call: a fixed bitrate wastes bits on simple scenes and starves complex ones, while a quality target spends what each scene needs.
Frame rate is a third lever people reach for and usually should not. Dropping 30fps to 15fps halves the frames but makes motion visibly stuttery, and it saves less than the resolution change because consecutive frames compress well against each other anyway.
# What a remux looks like at the command line. -c copy is the whole trick:
# copy the streams, do not decode them.
ffmpeg -i input.mov -c copy output.mp4
# Compare to a real conversion, which decodes and re-compresses every frame.
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
The first command finishes in about the time it takes to read the file. The second takes as long as the video is complex. Any browser-based converter worth using makes the same distinction internally, and the video converter does.
What happens to the audio when the container changes?
On a remux, nothing at all. The AAC track is copied across byte for byte along with the video, which is why a MOV to MP4 conversion cannot degrade the sound: the same compressed audio data ends up in the new wrapper.
On a re-encode it depends on the target. WebM cannot carry AAC, so the audio is re-compressed to Opus, and that is a lossy step applied to already-lossy audio. It is rarely audible on speech and occasionally audible on music with a lot of high-frequency detail, like cymbals.
Sometimes the audio is the only thing you want. A recorded interview that was filmed but will be published as a podcast, a lecture you want on your phone, a soundtrack you are transcribing. Converting the whole video and then discarding the picture is the slow way round. The audio extractor pulls the sound out directly, and for MP4 and MOV sources it can copy the existing AAC track to an M4A without re-encoding, exactly the same trick as a remux. If the file you have is already audio and only the format is wrong, the audio converter handles that side.
One thing worth knowing: a video file can carry several audio tracks, for different languages or a separate commentary. Most browser-based tools, including this one, work with the first track. If your source has more than one and you need a specific one, that is a job for ffmpeg at the command line with an explicit stream selector.
Which format should you send, and to whom?
Most conversion work is really this question wearing a disguise. The honest answer is that MP4 with H.264 video and AAC audio is the right choice far more often than any other combination, because it is the only one that plays essentially everywhere without thought.
| Where it is going | Send | Why |
|---|---|---|
| A client, a colleague, email | MP4 (H.264/AAC) | Plays on every phone, laptop and browser made this decade |
| A website you control | MP4, with WebM as a second source | WebM is smaller at the same quality, MP4 is the fallback |
| Social platforms | MP4 | They re-encode whatever you send, so give them the cleanest input |
| An editing timeline | The original file | Every conversion before editing costs quality you cannot get back |
| A chat app with a size cap | MP4, compressed | Change the size, not the format |
| Inline in an email signature or a README | MP4 if allowed, GIF only if not | GIF is a fallback for places that refuse video, not a choice |
The row that saves the most grief is the editing one. People convert footage before importing it, lose quality, then edit and export, losing more. If a timeline accepts the original, give it the original and convert once at the end.
The other common mistake is converting when you meant to compress. "This file is too big for the upload limit" is not a format problem. Changing MOV to MP4 will not help, because the video data is identical. Making it smaller means re-encoding it deliberately, which is what the video compressor is for, or trimming the parts you do not need with the video trimmer first. Thirty seconds you cut is thirty seconds nobody has to encode, and it beats any quality setting.
How does this compare to converting images?
The same container-versus-codec split exists for images, with the same consequence: some conversions are cheap and lossless, others throw information away. Converting a PNG to a BMP keeps every pixel; converting it to a JPEG does not. The image format converter guide covers that side, and the image compression guide covers the lossy-versus-lossless distinction in more depth than fits here.
The practical difference is scale. A bad image conversion costs you one picture. A bad video conversion costs you eleven minutes and a client asking why the text looks fuzzy.
Common questions
Is MOV or MP4 better? Neither, for most purposes, because they usually contain the same video. MP4 has wider device support, so it is the safer default for sharing. MOV is what Apple tools produce, and it carries some professional codecs that MP4 does not.
Why did my converted file get bigger? You converted to a less efficient codec or container, or to GIF. A remux never meaningfully changes the size; an encode to an older codec can easily grow it.
Why does my MP4 not play on an old device? The container is fine; the codec is not. An H.265 stream in an MP4 wrapper will not play on hardware that only decodes H.264, even though the extension looks familiar. This is the clearest case of the layers mattering.
