Appruva vs Email Attachments for Client Photo Approval

Where Email Attachments Break First: Size Limits

Email was not built to carry binary files. Every attachment gets Base64-encoded before it travels, and that encoding inflates the file by roughly a third — a 20MB JPEG batch arrives at the sending server as about 27MB. That overhead is why the usable ceiling under a stated cap is always lower than the cap itself, and it is also why the cap feels inconsistent: a folder that measures 24MB in Finder can still bounce, because the number the mail server checks is the encoded size, not the one on disk.

Now run a real gallery through that math. Forty review-resolution JPEGs at roughly 2MB each is 80MB total. At Gmail's effective ~18MB per message, that is 80 ÷ 18 ≈ 4.4 — call it five separate emails, five subject lines, five reply threads, for one shoot. A 100-photo gallery pushes past ten separate messages. None of this is a Gmail problem specifically; Outlook's lower cap makes the split worse, not better, and a recipient's inbox can impose a third, even stricter limit that the sender never sees until the bounce comes back.

The usual workaround — zip the folder, or use a transfer service like WeTransfer — solves the size problem and creates the next one. A zip file does not open in the client's browser; they have to download it, wait for it to extract, and find a photo viewer that will step through forty files at once. A transfer-service link solves the size problem but usually expires, and it hands feedback back to email anyway — the delivery method changed, but the review method did not.

Version Chaos: Which File Did They Actually Approve?

Once a gallery is split across multiple emails, or replaced by a cloud folder link, version tracking becomes a manual job. A client replies to email three of five asking for a crop on "the second one" — second in that email, or second overall? A retoucher delivers a pass, the client wants one more tweak, and the corrected file gets forwarded as a new attachment with no link back to which approval round it belongs to. Six weeks later the folder has final.jpg, final_v2.jpg, and final_v2_client_edit.jpg, and nobody in the thread can say with certainty which one was actually signed off.

This gets worse, not better, the more people touch the file. A shoot that passes through a photographer, a retoucher, and a client each doing one revision pass generates three separate "final" copies before anyone has agreed on a naming scheme. Email has no shared workspace to hold those copies apart — each person's inbox is its own private archive, so "the version I have" and "the version they have" can silently diverge, and the only way to catch it is to compare files by eye.

Email was designed to move messages, not to track state. It has no concept of "this is the current approved version" — that has to live in someone's memory, or in a spreadsheet maintained alongside the inbox, which is one more thing to keep in sync by hand on every round.

No Context: Feedback Disconnected From the Image

A reply that says "can you brighten it a bit and also fix the one from the ceremony" is only useful to the person who already knows which photos those refer to. Email feedback lives in text, separate from the image it describes, so every comment needs a filename or a description to be actionable — and clients do not think in filenames. The result is a back-and-forth just to establish what is being discussed, before any actual revision work starts: a reply asking "which one, can you attach it again," then a second reply confirming, before the actual note has even been read.

It compounds with volume. One vague note on a three-photo proof is an easy guess. The same vague note buried in reply forty of an eighty-photo gallery thread means scrolling back through unrelated replies to reconstruct which image the client had open when they wrote it — assuming they remember, which after a few days they often do not.

Feedback tied directly to a specific frame — a comment pinned to the image itself — removes that translation step entirely. The comment and the photo are the same object; there is nothing to misidentify, and nothing to reconstruct after the fact.

No Record: Who Approved What, and When

Email has no formal approval state. "Looks good, thanks!" buried in a reply chain is not a record anyone can point to later — it is a sentence a client could plausibly forget sending, in a dispute over a late change request. There is no timestamped log of who clicked approve, no audit trail if a stakeholder further up the chain asks what happened, and no single place to check gallery status without re-reading the thread from the top.

The gap shows up at delivery time, not approval time. A photographer moves ahead with final retouching and printing on the strength of a one-line reply, and three weeks later the client asks for a change "before it's too late" — except by their account, they never actually said yes to the version that went to print. Whoever is right, there is no record to settle it, only two people's memory of a thread neither can fully re-read without scrolling for ten minutes.

Client Photo Approval: Email vs. Appruva Side by Side

None of this makes email attachments a bad tool in general — it makes them a tool that was never built for reviewing a gallery, and the seams show exactly at the four points above once a shoot grows past a few frames. A tool built specifically for photo approval does not have to solve size limits, version tracking, feedback context, and approval records as four separate problems, because they were the design brief from the start, not a workaround bolted onto a messaging protocol from 1982.

When Email Attachments Are Still Fine

For a three-photo proof to a single point of contact, none of this matters. Size limits do not bite under a few megabytes, there is only one recipient to lose the thread, and one round of feedback rarely needs a formal record. Sending a headshot retake option or a single hero image for a quick yes or no is exactly what email is good at — fast, familiar, and zero setup on either end.

The failure points above are a function of volume and duration — more photos, more rounds, more people in the loop — not a flaw in email itself. A wedding gallery with 40+ selects, three stakeholders, and two revision rounds sits at the opposite end of that scale from a single headshot retake, and it is worth noticing which end a given job falls on before defaulting to whatever method was used last time. The question worth asking before a shoot is less "email or a tool" and more: how many photos, how many rounds, and how many people get a vote on this one. For a fuller walkthrough of what replaces the thread once volume passes that point, see running a client approval round without email.