Email attachment size limits compared across providers (and a client-ready workflow for photographers)

Email attachment size limits compared across providers: for most people, the practical limit is around 20-25 MB per message. That is why a single full-resolution JPEG set, a short 4K clip, or a zipped gallery often fails to send. For client delivery, treat email as the notification layer (message + link), not the delivery method.

Email attachment size limits compared across providers (quick table)

Limits change, and organisations can enforce stricter policies than the provider default. These numbers are best thought of as the usual ballpark most creatives run into in real life.

A photographer’s delivery workflow (from final export to delivered-to-client)

This walkthrough assumes you are delivering either (a) a finished JPEG gallery, (b) a small set of high-res finals, or (c) a mix of finals + print files. The goal is simple: your client gets one clean link, downloads reliably, and you do not get stuck in attachment error loops.

1) Final export: make the files client-proof

• Export finals into a dedicated folder named clearly: ClientName_Project_Delivery_YYYY-MM-DD.
• Stick to predictable formats: high-quality JPEG for general delivery, plus TIFF/PSD only if the contract calls for it.
• Consider two subfolders: Web (sRGB, smaller) and Print (full-res, print-ready). This reduces client confusion and cuts “can you resend the larger ones?” emails.

2) Quality check: catch the mistakes that cause re-sends

• Open a handful of exports at 100% to confirm sharpening, noise reduction, and watermarking (if used).
• Scan filenames for consistency. Clients often download and forward your files, so clean naming prevents “IMG_3948_FINAL_FINAL.jpg”.
• If you are delivering a lot of images, include a simple README text file with short instructions (what is inside each folder, and which set to use for social vs print).

3) Estimate size, then decide: attachment vs link

As soon as your delivery folder is bigger than 20-25 MB, assume email attachments will not work for at least some clients.

• OK to attach: 1-3 small JPEGs for quick review, a low-res proof, or a single PDF invoice.
• Use a link instead: galleries, full-res finals, RAW selects, zipped project folders, anything the client must download reliably.

If you want a deeper step-by-step on Gmail specifically, see Gmail attachment size limits and what to do instead (step-by-step).

4) Package the delivery folder (only when it helps)

Zipping is useful when you must preserve folder structure or reduce the number of clicks for the client. It does not magically make a large delivery “emailable”, and it can make some corporate mail filters more suspicious.

• Zip when: you have multiple subfolders (Web/Print), or you are delivering a set that must stay together.
• Do not zip when: the client needs to preview images easily one-by-one, or when you are using a service that already presents a neat download experience.

5) Send via a transfer link (cleaner than attachments)

This is the step that replaces the painful “try splitting into 6 emails” routine.

1. Upload the delivery folder (or zip) to a transfer-link service.
2. Set an expiry that matches your workflow (for example, 7-30 days depending on the project and client responsiveness).
3. Add a password when the work is sensitive (celebrity shoots, unreleased campaigns, personal events, architectural sites not yet public).
4. Generate one link and keep it as the single source of truth.

If you want a simple option focused on private, expiring links, you can send a file free and share the download link with your client. If you are comparing capabilities like expiry and access controls, see all features (or compare Free and Pro if you need larger transfers or longer retention).

6) Write the client email (email is for context, not payload)

Keep it short and specific. A good client delivery email includes:

• What is included (for example, “40 edited finals in Web + Print folders”).
• The link and password (send the password separately if your client process requires it).
• The expiry date (so they know to download promptly).
• One instruction line: “Click Download, then unzip to keep the folders intact.”

7) Confirm receipt without chasing

Instead of “did you get it?”, set an expectation:

• “Let me know once you have downloaded everything, and I will archive the delivery.”
• If you are working with an agency, ask them to confirm the correct internal recipient before you send (one bad address wastes a day).

8) Archive your delivery like a pro

• Save the exact delivered set in your archive so you can re-send the same package later.
• Store the link, expiry, and any notes in the project record (CRM, Notion, spreadsheet, whatever you use).
• If you need help troubleshooting failed uploads or client downloads, visit the Help Center or read the FAQs.

Attachment limits are only half the problem (the other half is deliverability)

Even under the nominal cap, attachments can still fail because of:

• Corporate security filters stripping zips or blocking certain file types.
• Mailbox quotas (yours or the client’s) causing silent bounces.
• Unreliable mobile sending on slow connections.
• Version confusion when you send “final_v3” in a new thread.

A single expiring link avoids most of this: one URL, one package, one place to pull the correct files.

Quick decision checklist (photographers)

• If the delivery is under 20 MB and not sensitive, an attachment is fine.
• If the delivery is over 20-25 MB, use a transfer link.
• If the client is a corporate domain, assume stricter rules, use a link plus expiry.
• If the work is confidential, use password protection and a shorter expiry.
• If the package has folders, consider a zip, otherwise keep it simple.