2026-09-10

Why the video you text looks blurry (and how to compress one yourself before you send it)

You film something in one take, it looks fine on your own screen, you text it to someone, and it arrives soft, blocky, and stuttering — as if it had been recorded on a much older phone. The camera is not the problem. Somewhere between your phone and theirs, a carrier network quietly re-encoded your video down to a file smaller than most people's photos, because MMS — the protocol underneath a plain green-bubble text — was never built to carry video at today's resolutions.

The cap most people never see, until they hit it

MMS has hard byte limits, set by the carrier, not by the app you're using. AT&T's own support page states it outright: "The AT&T mobile broadband network delivers picture, video, or audio messages of up to 1MB," and that "larger media file attachments are compressed before sending to keep the message size below 1MB." Verizon and T-Mobile aren't more generous — per Twilio's carrier comparison, Verizon caps images at 1.2MB and video at 3.5MB, while T-Mobile allows 1MB to send and 3MB to receive over plain MMS. A short, sharp phone recording of a birthday cake or a kid's first steps can easily be 30-50MB straight off the sensor — thirty to fifty times over any of those numbers before a single byte gets sent.

Two different roads out of your phone, and only one of them compresses

Apple's own explainer draws the line clearly: iMessage and RCS both carry "high resolution photos and videos," the same phrase repeated for both — while plain SMS/MMS is described only as carrying "photos and videos," with no such qualifier. That's not an accident of wording. iMessage (blue bubbles, Apple-to-Apple) and RCS (green bubbles, but with rich features, now supported between recent iPhones and Android phones) both route media over the internet at something close to its real size. Fall out of both — texting someone whose phone doesn't have RCS turned on, sending to an older device, a spotty data connection at the moment you hit send, certain group threads, or a messaging app that doesn't negotiate RCS at all — and the message quietly drops down to plain MMS, where the 1-3.5MB ceilings above apply.

Most people never choose this. It's a fallback the phone makes for you, silently, message by message, and you generally only notice on the receiving end, weeks later, wondering why a video looks like it was filmed underwater.

What the phone actually does to hit that number

How-To Geek's explanation of the blue-bubble/green-bubble quality gap puts it plainly: carriers "impose strict file size caps, often around 1 MB or less," and when a video falls back to MMS, "your iPhone automatically compresses the video to fit within those limits, resulting in a blurry, pixelated version of what you recorded." The phone isn't being lazy — it genuinely has no other way to fit forty seconds of 4K footage into one megabyte except to throw away most of the picture quality, and it makes that call for you with zero input: no choice of resolution, no choice of which few seconds actually matter, no warning before it happens. Forward that same already-compressed clip again later, and it gets compressed a second time on top of the first.

Compress it yourself first, and you make the trade-off instead of the carrier

The carrier's compression is blind: it doesn't know which three seconds of your forty-second clip matter, so it squeezes everything evenly and hopes. NearVid's Trim is a lossless stream copy — no re-encode, no quality loss — so the first move that actually helps is cutting the clip down to just the part worth sending, entirely on your device, before any compression enters the picture at all. A ten-second trim starts from a much smaller original than a forty-second one, which means whatever compression follows — the carrier's or your own — has far less ground to make up.

From there, NearVid's Convert to WebM re-encodes at a quality preset you pick — High, Medium, or Low, corresponding to 2Mbps, 1Mbps, and 500kbps of video, each carrying roughly 128kbit/s of audio — and the export screen shows an "≈" size estimate for your chosen trim and preset before you commit, computed from those same bitrates rather than a live test encode. On Chrome and other Chromium-based browsers where WebCodecs H.264 encoding is available, the feature-detected Convert to MP4 card does the same job at 4Mbps/2Mbps/800kbps — worth choosing over WebM for texting specifically, since plenty of phones still can't open a WebM file at all, while H.264 MP4 is the one format virtually every phone's own gallery app can play without asking.

Running the same labeled-approximation math the app's own estimate uses — preset bitrate plus ~128kbit/s audio, times duration — the Low WebM preset holds roughly 13 seconds under AT&T's or T-Mobile's 1MB send cap, about 38 seconds under T-Mobile's 3MB receive cap, and about 45 seconds under Verizon's 3.5MB video cap. Medium and High presets buy noticeably higher quality per second at the cost of fewer seconds fitting the same budget — which is exactly the trade a carrier's blind auto-compressor never lets you make, because it never tells you the budget exists in the first place.

What this doesn't fix

NearVid has no idea which carrier your recipient is on, whether their phone has RCS turned on, or whether your particular message will go out over iMessage, RCS, or fall back to plain MMS — none of that is visible to a page running in your browser, and nothing here reaches into your Messages app to send anything. What NearVid does is the part that happens before you open Messages at all: trim to the seconds that matter, re-encode at a size you can estimate in advance, in a format built for playback rather than upload. Whether that file goes out full-quality over RCS or gets compressed again by a carrier's MMS gateway, it's starting from something already small and already yours to choose — not forty seconds of 4K handed over for the network to butcher on its own terms.

The honest summary

Plain MMS caps video at 1MB on AT&T and for T-Mobile sends, 3MB for T-Mobile receives, and 3.5MB on Verizon — per each carrier's own published limits — and a phone that can't reach iMessage or RCS falls back to that ceiling silently, compressing whatever you sent down to fit it, which is why texted videos so often look blurry and blocky with no warning it was coming. The fix available inside a browser: trim losslessly to the part worth sending, then re-encode with NearVid at a quality preset you pick and a size you can see in advance — WebM everywhere, or MP4 when WebCodecs support is there — so the seconds that survive are the ones you chose, not whatever a carrier's compressor left behind.