halfsize / Blurry after sending
It looks worse after sending because it was compressed twice
You compressed once, checked the result, and it looked fine. Then you sent it, and it came back soft. The delivery app did not pass your file along — it decoded your file and encoded a new one to save its own storage. Every chat app is a second compressor you did not configure.
Who re-encodes, and who hands over the bytes
| Where it goes | What the app does | How to keep the original |
|---|---|---|
| WhatsApp, sent as media | re-encodes; typically 720p, own bitrate | send as Document |
| Telegram, sent as video | re-encodes into its streaming ladder | send as File, or "send without compression" |
| WeChat chat video | re-encodes; resolution follows the app | 原视频 toggle, or send via File |
| iMessage | re-encodes large videos, often hard | no switch; use Mail, AirDrop or a file link |
| Discord, under the upload cap | passes the file through | nothing to do |
| Email attachment | base64 only, bytes unchanged | nothing to do |
| Drive / OneDrive link | stores the file as is | nothing to do |
Read that table as: the platform you send through decides whether your encode survives. Discord and email deliver exactly what you made. WhatsApp, Telegram, WeChat and iMessage deliver their own encode of what you made, which is why the same file can look good on your laptop and poor on the recipient's phone.
Why the second pass hurts more than the first
Encoders are efficient at removing information a viewer would not notice, but only once. The first pass leaves behind fine texture, gradient steps and motion that sit just above the visibility threshold. The second pass has no such reserve to spend: it removes the same kind of detail again, and now it is visible.
The arithmetic is simple and does not need a measurement to be true. Suppose your clip is 60 seconds long and you compressed it to 20 MB. That is about 2.4 Mbps of video (20 MB × 8000 ÷ 60 s, minus audio and overhead). If the app re-encodes it at its usual 720p budget of roughly 1 Mbps, it keeps 40% of the bits you just decided were the minimum acceptable. Whatever VMAF your file scored the first time, the delivered copy is scored on the delivered copy.
The one rule that fixes most of this: if the app is going to re-encode anyway, do not spend bytes it will throw away. Either get under its threshold so it passes the file through, or send it in a mode that transfers bytes — Document, File, attachment, link.
Fix 1: send as a file
Every messenger in the table has a mode that treats your video as an opaque file. The recipient gets a download prompt instead of an inline player, which is the trade. If the video is something a person will keep — a wedding, a property walkthrough, a demo for a client — that trade is clearly worth it.
The app's file limit still applies. That is the only number you need to respect, and it is usually larger than the media limit: WhatsApp's document limit is well above its 16 MB media cap, so a 50 MB file goes through untouched even though it could never be sent as media.
Fix 2: compress to what the app will accept, once
If it has to be media (inline playback matters), then compress to the app's actual budget in one pass, at the resolution the app would use anyway. Compressing to 1080p when the app is going to deliver 720p means half your bits are discarded before anyone sees them.
$ npx halfsize holiday.mp4 --for whatsapp
target 16.0 MB
plan H.264 960x540 1.94 Mbps audio 128 kbps 2-pass
scale 1920x1080 → 960x540
136 MB → 15.59 MB 8.7x smaller 2.6% under target
VMAF 84.8 slight softeningThe presets use the caps the apps publish for the free tier. At 16 MB for one minute the budget is 1.94 Mbps, which carries a clean 540p frame but not 720p, so the planner picks 540p instead of a soft 720p. That is the same trade the app makes, except you see the quality score before sending rather than after.
How to tell whether your file was re-encoded
Compare the file you sent with the file the recipient saved. Resolution, bitrate and duration are usually enough:
$ ffprobe -v error -select_streams v:0 -show_entries stream=width,height,bit_rate -of default=nw=1 sent.mp4
width=1920
height=1080
bit_rate=8143221
$ ffprobe -v error -select_streams v:0 -show_entries stream=width,height,bit_rate -of default=nw=1 received.mp4
width=1280
height=720
bit_rate=1041888Same clip, 8 Mbps at 1080p in, 1 Mbps at 720p out. No amount of tuning on your side changes that; only the delivery mode does.
Two more causes of a "blurry" video
- It is grey, not blurry. HDR footage sent through a tool that drops the transfer curve looks flat and washed out. That is a different bug with a different fix.
- It was never sharp. Cheap phone lenses, digital zoom and heavy denoise all look like compression damage after one pass. Compression makes soft footage softer, faster.
FAQ
Why is it blurry on WhatsApp?
WhatsApp re-encodes media, usually to 720p at its own bitrate. Your file was already compressed once; this is the second generation, and it removes detail the first pass kept.
Does sending as a document avoid it?
Yes. Document/File mode transfers the original bytes. The recipient taps to download and play, and the app's file limit still applies.
It was under 16 MB and still looked bad — why?
The size limit and the encoder are separate. A clip under the cap is still re-encoded, and resolution is often capped at 720p regardless of size.
Does the same happen on iPhone?
iMessage re-encodes large videos and has no "send original" switch for video. AirDrop, Mail or a file link keeps the bytes intact.
Can I fix the received file?
No. Re-encoding it again just adds loss. Ask for the original, and send as a file next time.