Rewrap or Re-encode? What Turning a 130 MB .MOV and a 113 MB .WebM Into MP4 Actually Does

"Convert it to MP4" sounds like one job. It's really two different jobs that happen to produce a file with the same extension:

• Rewrap: move the same video and audio packets into an MP4 container. It takes seconds, the size stays the same and the picture can't get worse, because nothing is decoded.
• Re-encode: decode the video and compress it again as H.264. It takes longer and costs some quality, but it's the only route that makes the file smaller or changes what's inside.

Which one you need depends on two questions: what codec is inside your .mov or .webm, and does the place you're sending it care about the extension, the codec or the megabytes? I ran both routes on two real files: a 130 MB iPhone-style .MOV and a 113 MB screen recording saved as .WebM. Everything ran in Chrome on videocompress.dev, a browser video tool I build (so read this with that in mind). Nothing was uploaded, and I checked every output with ffprobe.

The short answer (measured)

File	Route	Result card	Bytes on disk	What's inside	Time
.MOV, H.264 + AAC, 1920×1038, 1:30	Rewrap (/mov-to-mp4)	123.7 MB → 123.7 MB	129,660,347 → 129,660,321	same H.264 + AAC packets	2.6 s
.WebM, VP9, 1920×1080, 1:35	Rewrap (/mov-to-mp4)	108.2 MB → 108.2 MB	113,485,308 → 113,491,587	still VP9, now in an .mp4	2.1 s
.WebM	Re-encode, Target size 10	108.2 MB → 9.4 MB · 91% smaller	113,485,308 → 9,872,090 (−91.3%)	H.264, 1920×1080	9.1 s
.MOV	Re-encode, Quality → Small file	123.7 MB → 24.5 MB · 80% smaller	129,660,347 → 25,675,202 (−80.2%)	H.264 + AAC, 1920×1038	12.1 s

The site's "MB" are binary megabytes (MiB), which is why 129,660,347 bytes shows as 123.7 MB. The byte column is exact.

Step 1: Look inside the file before you pick a route

The extension tells you the container. It doesn't tell you the codec, and the codec is what decides whether a rewrap is enough. Drop the file on the video inspector. It reads the container in the tab and shows the codec string, bitrate and keyframes without producing a new file.

The .MOV: QuickTime container, video avc1.640028 (H.264 High), audio mp4a.40.2 (AAC), 1920×1038 at 24 fps, 11.5 Mbps overall, 124 MB. That's exactly what an MP4 normally carries.

The .WebM: video vp09.00.40.08… (VP9), 1920×1080, about 9.6 Mbps, no audio track, 108 MB. Its "bits per pixel" is 0.158, and the inspector flags that as "a lot of room to compress", which is typical for screen recorders that write at a fixed high bitrate.

Rule of thumb from these two: avc1/hvc1 + mp4a means a rewrap is possible. vp8/vp09/av01 means you can still rewrap, but the result won't be the H.264 file most people expect when they say "MP4". The next two steps show that difference.

Step 2: Rewrap the MOV (seconds, same size, identical picture)

Open MOV to MP4, drop the .mov and press Convert to MP4. The page tries a straight stream copy first, falls back to re-encoding only the audio if the MOV holds PCM sound, and does a full re-encode only for codecs that can't live in MP4 (ProRes and friends).

My 129,660,347-byte MOV came back as a 129,660,321-byte MP4 in 2.6 seconds, with the card saying "Rewrapped — the video and audio were copied, not re-encoded." I checked that claim with ffmpeg's per-stream packet hashes, and they're identical for both the video and the audio stream (screenshot in Step 6). So it's the same picture, bit for bit, with a different extension.

If a Windows app, a CMS or a web form only rejected the .mov extension, you're done here. Don't re-encode a file that only needed a new container.

Step 3: Rewrap the WebM too, and notice the trap

The same page accepts WebM ("MKV, AVI, WMV and WebM work too"). I dropped the screen recording in, and it also "rewrapped" in 2.1 seconds: 108.2 MB → 108.2 MB.

But look at what's inside: ffprobe shows vp9 / vp09. It's a valid MP4 (the packet hash matches the WebM exactly) and it plays in Chrome, but it's still VP9 at 113 MB. Anything that expects H.264 inside an .mp4, such as an older TV, some Windows or Mac apps, or an upload checker that looks for avc1, may still refuse it. It also hasn't shrunk at all.

So for a VP8/VP9 WebM the useful route is almost always a re-encode. That's next.

Step 4: Re-encode the WebM to H.264 under a size cap

Go to the compressor on the homepage and drop the .webm. With no changes it estimated ≈ 59.5 MB (Balanced). I wanted something that fits a 10 MB attachment box, so I switched to Target size and typed 10. The estimate went to ≈ 9.4 MB.

Press Compress video and keep the tab in the foreground. It finished in 9.1 seconds: 108.2 MB → 9.4 MB · 91% smaller.

The download is 9,872,090 bytes, which is 9.87 MB in decimal or 9.41 MiB, so it's under 10 by either definition. Inside it's H.264, 1920×1080, about 0.83 Mbps, still 1:35 long. Screen recordings compress this well because most frames barely change. The screen recording page explains why they're recorded so fat in the first place.

Step 5: Re-encode the MOV when the size is the problem

If the MOV was rejected for being too big rather than for its extension, the rewrap from Step 2 doesn't help, because it's still 124 MB. Back on the homepage, drop the .mov. The default Balanced estimate is ≈ 32.2 MB. I picked Quality → Small file (estimate ≈ 16.8 MB).

12.1 seconds later: 123.7 MB → 24.5 MB · 80% smaller.

Note that the real file came out bigger than the estimate. This clip is detailed CG with lots of thin, moving wires, and the browser encoder needed about 2.1 Mbps for it. The estimate is a pre-encode guess, and the result card is what counts. On disk it's 25,675,202 bytes, still H.264 + AAC at 1920×1038, and the audio stream wasn't touched (194 kbps both before and after). If you have a hard limit, compare the card with that limit before you send. For dense footage like this, dropping to 720p buys more headroom than squeezing the bitrate.

Step 6: Verify bytes, codecs and the "copied, not re-encoded" claim

Three checks on the downloads: sizes from the file system, codec and tag per stream from ffprobe, and per-stream MD5 of the compressed packets (ffmpeg -i FILE -map 0 -c copy -f streamhash -hash md5 -). Same hash = same packets.

• MOV → rewrap: H.264 + AAC, hashes identical, 26 bytes smaller (container overhead).
• WebM → rewrap: VP9 in MP4, hash identical, 6,279 bytes bigger.
• WebM → re-encode: H.264 avc1, 9,872,090 B.
• MOV → re-encode: H.264 avc1 + AAC, 25,675,202 B.

Step 7: What the re-encode cost (100% crops)

Rewraps cost nothing, so only the two re-encodes need a look. These are unscaled crops from frames of the source and the output:

The screen recording's text survived at 0.83 Mbps: small grey labels are slightly softer, and every word is still readable. The MOV lost fine texture in the wires and the dark background at 2.1 Mbps. That's fine for sharing, but if the clip is going back into an editor, keep the rewrap and send the big file another way.

Which MP4 do you actually need? (checklist)

1. Only the extension was rejected and the inspector shows avc1/hvc1 + mp4a: rewrap. It takes seconds and loses nothing.
2. The codec is VP8/VP9/AV1 (most .webm files) and the destination wants "normal MP4": re-encode to H.264, even if size isn't an issue.
3. The file is too big: re-encode with Target size (or a Quality preset), then read the result card, not the estimate.
4. The MOV is HEVC (newer iPhones): a rewrap keeps it HEVC. That's fine on Apple devices, but for older PCs or players a re-encode to H.264 is the safer choice.
5. Afterwards, check the extension, the codec (avc1 for maximum compatibility) and the byte size against the destination.

Both routes run locally in the tab. This comparison explains why the rewrap page uses ffmpeg.wasm while the compressor uses WebCodecs.

If a recording is too long for a browser tab to handle (multi-GB meeting files, for example), the cloud compressor vidsmaller.com from the same team is the better fit.

About the test files

The .MOV is a 90-second cut (from 1:00) of Elephants Dream (2006, Blender Foundation / Netherlands Media Art Institute, orange.blender.org, licensed CC BY 2.5). I took the left-eye half of the stereo 3D release on download.blender.org/ED and re-encoded it with ffmpeg as H.264 High (about 11.3 Mbps) plus AAC 192k in a .mov with the avc1 tag, the same layout an iPhone writes. The .WebM is a 95-second, 1920×1080 screen recording I made of a Chrome window scrolling videocompress.dev pages, saved as VP9 at a fixed 9 Mbps with no audio, the way many recorders save screen captures. Runs: 2026-10-21, headless Chrome 155 on Linux.

Related: Why .webm and .mov get rejected, and the smaller-MP4 fix (DEV.to) · Measuring the base64 tax on a video email attachment (Hashnode) · The 25MB email limit is smaller than it looks (Medium)