Text Message Photo Approvals: Fast, and Quietly Expensive

What Actually Happens When You Text a Photo

Every major U.S. carrier caps MMS attachments hard, and none of them ask before compressing to fit. Current carrier support documentation puts the ceiling at roughly 1 MB for AT&T, 1.2 MB per image for Verizon, and up to 3 MB for T-Mobile. Send across carriers — an AT&T client texting a photo to a friend on Verizon, say — and the message renegotiates down to whichever cap is lower, silently, with no warning on either end.

Run the math on a typical 12 MB full-resolution export: AT&T's roughly 1 MB cap keeps about 8% of the original file (1 ÷ 12 = 8.3%), Verizon's 1.2 MB keeps 10%, and T-Mobile's 3 MB tops out at 25%. Whichever carrier wins that negotiation, the client is judging skin tone, product color, or retouching detail on a fraction of the data you delivered.

Apple-to-Apple iMessage and Android-to-Android RCS both route over data instead of the carrier's MMS network, so quality holds up far better — but the instant either side drops to plain SMS/MMS (no signal, an iPhone texting an Android without RCS turned on), the same hard caps apply again, and neither person gets a warning that it happened.

How much this actually matters depends on what's in the frame. A quick candid at a family session can survive an 8% file — the client is checking for a closed eye or an awkward smile, not judging tone curves. Product photography for an e-commerce listing, a wedding portrait where skin tone has to match across a whole gallery, or a real estate shot where a client is deciding whether a wall color reads true — those are exactly the judgments an MMS-compressed JPEG makes hardest, because compression artifacts show up first in smooth gradients: skin, sky, and painted walls. The client isn't wrong to say a photo "looks a little off" over text. They're often looking at a file that lost most of its color information before it ever reached them, on a screen that is doing its own compression and color rendering on top of the carrier's.

None of this requires the client to know anything about codecs or carrier networks. It only requires you to know it, so that when a text approval comes back with a vague complaint about color or sharpness, the first question is whether the file that generated the complaint was ever a fair copy of the work in the first place.

The Real Cost of "Which One Do You Mean?"

Compression is only half the problem with text message photo approvals. A text thread has no way to reference frame 4471 — only "the one with her looking left" or a screenshot with a red circle drawn on it. That ambiguity, not the file size, is where the actual time goes.

That middle figure is a model, not a survey result, so here is the arithmetic behind it: assume two rounds of "wait, do you mean this one or the other one" per shoot, each costing about 15 minutes of back-and-forth before the client confirms which frame they meant. Across 8 shoots a month, that is 2 × 15 × 8 = 240 minutes, or 4 hours, spent entirely on identifying the photo rather than discussing the edit. Change the assumptions for your own shoot volume and the number moves, but the shape of the cost doesn't — it scales with how many photos you deliver, not with how good your clients are at giving feedback.

A Concrete Scenario: One Revision Round, Two Ways

Say a corporate client has narrowed 40 headshot options to 6 finalists and wants two of them re-touched — soften a shadow under the jaw, brighten the background on the other. Over text, that round typically runs: the client sends a screenshot of the gallery thumbnail grid with two circles drawn in a markup app, you reply asking which row is row 2 because the screenshot cropped the file names, they resend with the file names visible, you confirm the two frame numbers back, and only then does the actual edit note arrive. That's four messages and two waiting periods before any retouching starts, and the screenshot itself is a second-generation compression of an already-compressed MMS thumbnail.

Over a review link with per-frame comments, the same round is one message: the client opens the gallery, clicks the two frames, and leaves the note directly on each one — "soften the jaw shadow" pinned to frame 14, "brighten the background" pinned to frame 22. There's no intermediate step where anyone has to figure out which thumbnail the other person means, because the comment already lives on the image it's about. The compression math from the first section explains why the file looks different; this is the mechanical reason the back-and-forth takes longer, too — a text thread has no address system for an individual photo, so every round has to invent one from scratch.

When a Text Is Actually the Right Call

None of this means banning texting. It means being precise about what it's for, and the test is whether the message needs to survive as a record later.

• Good use: a single candid preview mid-shoot, just to confirm you're capturing the right moment — nobody needs to reference it again next week.
• Good use: day-of logistics — "running 10 minutes late," "parking is around back." Nothing here is a creative decision.
• Good use: a nudge that a full gallery is ready, with a link to the actual review, so the client knows to go look.
• Bad use: the only record of a final approval, with no frame reference and no timestamp attached to it.
• Bad use: collecting revision notes on compressed images the client can't actually judge color, sharpness, or a subtle retouch from.

The line is simple: texting is fine for anything that doesn't need to outlive the conversation. The moment a message needs to answer "did the client approve this exact frame, and when," a thread that scrolls out of view — on a file that was never full quality to begin with — is the wrong tool for the job.

What Replaces the Thread

This is the same failure mode that shows up whenever a delivery mechanism doubles as a feedback channel. WeTransfer links expire and carry no comment thread at all, and replacing an email-based approval round with one review link fixes the same root issue text messaging has: too many channels, no single source of truth for what was actually approved. Email, WeTransfer, and MMS fail for different mechanical reasons — a dead link, a buried reply-all, a compressed file — but the fix is the same shape in every case: one link, one place the approval lives, full resolution the whole way through.

A tool built for this — Appruva included — keeps the file at full resolution and pins every comment to the frame it's about, so "which one do you mean" stops being a question anyone has to ask. That matters most for exactly the shoots where texting is tempting because it's fast: a same-day turnaround, a client traveling and only checking their phone, a rush job where nobody wants to open a laptop. The link works on a phone just as fast as a text does — it just doesn't throw away the file getting there, and it doesn't forget what was decided the moment the conversation moves on to the next thing.

The switch costs nothing to make. Most review tools generate a link the same way a gallery does today; the difference is what happens after the client opens it. Instead of a reply that has to be manually copied into a project tracker, or read back off a phone screen days later, the approval itself becomes the record — timestamped, tied to the exact frame, and still there if a dispute over what was approved ever comes up months after delivery.