How to Deliver Final Photos to Clients After Proofing

Published

A proof contact sheet with four selections sits beside two matching sets of the selected final photographs.

The client has chosen the photographs. The edits are finished. That does not mean every client-visible image belongs in the final delivery.

Your proof gallery may still contain unedited options, rejected frames, low-resolution previews, comments, favorites, and selection history. Your working folders may contain RAW files, catalogs, layered edits, temporary exports, and duplicate versions.

The final handoff should be narrower.

A photo delivery is final when proofing is over and the client can identify, download, and retain the complete agreed set in the versions they actually need.

That definition helps you decide both what to send and how to send it. If the client still needs to choose favorites, comment, approve edits, browse a visual gallery, or order prints, keep using the gallery workflow. If those jobs are finished, you can prepare a final-only delivery.

First, decide whether proofing is actually finished

A proof and a final photograph can both be JPEGs. The difference is not the file extension. It is what the client is expected to do.

Proofs exist to support a decision:

  • choose favorites;
  • request edits;
  • compare similar frames;
  • comment or approve;
  • confirm the final selection.

Final files exist to complete the agreement:

  • download the selected photographs;
  • use them on a website or social profile;
  • retain a full-resolution copy;
  • send a file to a named print lab;
  • share approved photographs with another person.

Do not move into final delivery while selections or review rounds are still open. A simple folder or download link removes context that a proofing gallery may still need to preserve.

Name the milestone that ended proofing. It might be the client’s submitted favorites, written approval of the edited set, or completion of the agreed revision round. Then freeze the selected count.

If 12 photographs were selected, the final package should account for those 12. That count becomes part of the handoff check.

Build the complete selected set

Start from the approved selection, not from the export folder.

For every promised photograph, record:

Selected filename:
Final edit complete: yes / no
Client use: screen / retained full-resolution / named print product
Required export:
Included in final package: yes / no

Keep the identifying part of the filename stable when the client selected proofs by filename. If ACME-Brand-014 was the selected proof, the web and full-resolution finals should still make ACME-Brand-014 easy to recognize.

Then remove anything that does not belong:

  • unselected proofs;
  • rejected or duplicate frames;
  • contact sheets and temporary previews;
  • test exports;
  • Lightroom or Capture One catalogs;
  • working Photoshop files;
  • RAW files that are not included in the agreement.

The goal is not the smallest possible package. It is an accountable one: every agreed final is present, and every included file has a reason to be there.

Export for what the client will do

“High resolution” is not a complete delivery instruction. Neither is “print-ready.”

Choose each export because of a specific use.

Web or screen use

A client publishing photographs on a website or social channel may need smaller exported copies that are practical to upload and share. Choose the pixel dimensions, file type, color profile, and compression for that use.

Adobe’s Lightroom Classic export guidance treats file format, image sizing, and output sharpening as separate export choices. Its casual-sharing dimensions are examples, not a universal client standard.

Retained full-resolution use

If the agreement includes a full-resolution final set, export the edited photographs at the intended final dimensions and quality. Label that set clearly so the client does not mistake preview files for the files they should retain.

“Full resolution” should describe the delivered export, not imply that the client receives the RAW capture or working edit.

Ask which lab and product will be used before creating a special print export. There is no single file specification that every printer wants.

For example, Bay Photo accepts JPG, PNG, and TIFF under specific conditions and describes 200–300 PPI at print size. WHCC asks for high-quality JPEG print files, says most products print at 300 DPI, and provides templates for products that need them.

Those requirements overlap, but they are not identical. Follow the selected lab’s current specification instead of promising that one generic export is ready for every print product.

If the client has not chosen a lab or print product, explain that rather than adding an unexplained PRINT folder.

Keep RAW and source-file delivery separate

The photographers’ working files and the client’s final photographs are different parts of the project.

A RAW file may preserve more capture data for later editing, but that does not automatically make it part of the handoff. The agreement should decide whether RAW files, layered edits, catalogs, or other working files are included.

If RAW delivery is included, treat it as a separate package and transfer decision. RAW sets can be large, may require specialist software, and may not belong in the same destination as the finished JPEGs.

Do not turn this into a universal “never deliver RAW” rule. Commercial, editorial, agency, or collaborator agreements can set a different boundary. The important step is to settle that boundary before the final link is sent.

Choose the experience the client still needs

The delivery method follows the client’s remaining job.

Stay in the gallery when the client still needs:

  • visual browsing and a curated sequence;
  • favorites, comments, or selections;
  • low-resolution previews linked to downloadable originals;
  • print ordering;
  • gallery-specific access or hosting.

A gallery can also remain the right final-delivery method when it already gives the client the intended downloads and presentation. Do not replace a workflow that passes the handoff check.

Use a final-only cloud folder

A separate Drive or Dropbox folder can work when the client needs familiar, persistent storage and download rather than a gallery experience.

Copy only the final selected files into that folder. Do not expose the working project folder merely because it already contains the exports.

For the broader choice among a working space, final folder, transfer service, workflow tool, and browser link, use the Google Drive alternative for client delivery.

Use a transfer service

Use a transfer service when one large download is the main job and package size, transfer speed, or temporary delivery matters more than presentation. Check the actual size and expiry limits before sending.

A final-only link can fit when selection is complete, the client only needs the files, and a clean downloadable list is enough.

Do not confuse that with a photography gallery. If thumbnails, favorites, proofing, or print sales matter, a file list removes behavior the client still needs.

Worked example: 12 finals from 60 proofs

Leah is an illustrative independent brand photographer. Her client reviewed 60 low-resolution proofs in Pixieset and selected 12 photographs. Leah has finished editing those 12.

She keeps the proof gallery and selection history where they are. They explain how the final set was chosen, but they are not part of the final download.

Leah exports the selected photographs into this package:

Client-Name-Final-Photos/
├── 00-READ-ME.txt
├── 01-WEB/
│   ├── ACME-Brand-014.jpg
│   ├── ACME-Brand-027.jpg
│   └── 10 more selected web-sized JPEGs
└── 02-HIGH-RES/
    ├── ACME-Brand-014.jpg
    ├── ACME-Brand-027.jpg
    └── the same 10 selected full-resolution JPEGs

The filename stems match the selected proofs. There are 12 files in each promised export set.

The read-me says:

01-WEB contains smaller copies for websites and social publishing.
02-HIGH-RES contains the full-resolution final exports to download and retain.
RAW files are not included in this project.
No universal print export is included. Ask for a file prepared to your chosen
lab and product if needed.

Leah now chooses the method:

  • If the client values Pixieset’s visual gallery and it already provides both downloads, she keeps Pixieset.
  • If the client wants a familiar persistent folder, she creates a final-only Drive folder.
  • If a clean file list is enough and the size, access, and expiry conditions fit, she can use a final file link.
  • If the high-resolution package exceeds the chosen method’s limits, she uses a suitable transfer service.

The package stays the same even when the delivery method changes.

Test the handoff as the client

Open the delivery outside your normal signed-in session and check:

  1. Final-set count: Are all 12 selected photographs present in every promised export set?
  2. Proof boundary: Are unselected proofs, comments, and review files absent?
  3. Filename continuity: Can the client connect selected proofs to the final exports?
  4. Original download: Does opening or downloading a file return the intended final dimensions rather than a preview?
  5. Complete download: Can the client download the whole promised set?
  6. Mobile and logged-out access: Does the intended recipient state work?
  7. Access: Is the delivery public, password-protected, private, or otherwise restricted as intended?
  8. Expiry: Will the destination remain available long enough for the client to download and retain the files?
  9. Print boundary: Does any print export match the named lab and product?
  10. RAW boundary: Does the package match the agreement about working files?

Fix a failed check before sending. A polished delivery email cannot repair a missing final, a preview saved instead of the original, or an expiry the client does not know about.

Where Litehost can fit

Litehost can enter after proofing when a selected set fits a browser-first file link and the client does not need a photography gallery.

On September 16, 2026, we tested Litehost’s anonymous, unclaimed Upload Free flow with five synthetic 1200 × 800 JPG, WebP, and PNG files totaling about 1.1 MB. The recipient link:

  • preserved the uploaded filename order;
  • returned byte-identical files with the original dimensions;
  • supported individual downloads and generated a Download All ZIP;
  • opened while logged out on desktop and at a 390 × 844 mobile viewport;
  • came with an API-supplied expiry of about 15 minutes.

The page showed filenames, sizes, generic image icons, and download controls. It did not show photographic previews. That distinction matters: this tested flow is a downloadable file list, not a proofing or portfolio gallery.

This test does not establish paid-plan behavior, large or high-resolution gallery behavior, permanent availability, RAW delivery, metadata or color rendering, proofing, selection, print sales, or photography CRM features. Confirm the exact file count, size, access, download, mobile, and expiry conditions for the configuration you intend to send.

Litehost is not needed when an existing gallery or final-only Drive folder already gives the client the right experience and downloads.

The final-photo delivery decision

Before sending, answer in order:

  1. Is proofing and selection finished?
  2. What is the complete agreed final set?
  3. Which exports does the client actually need?
  4. Are RAW or working files included by agreement?
  5. Does the client still need a gallery, or only a final download?
  6. Which method fits the package size, access, and retention period?
  7. Does the delivery pass the final-photo acceptance check?

When the answers are clear, send one message that states what is included, which files to use, how to download the complete set, and how long the delivery will remain available.