Should you keep rejected RAW files? Keep is the default

The question usually arrives as a yes or no, at midnight, with a full drive. It is neither. Keeping rejected RAW files is a policy with one narrow exception, and the useful work is deciding in advance which frames fall inside it. Here is the policy, the storage math behind it, and the gates a file has to pass before anything happens to it.

Why keep wins the argument before it starts

"Rejected" is a filing word, not a verdict. In Lightroom it is a flag. In Photo Mechanic it is a color class. In your head it means "not this one, for the gallery, tonight." None of those are the same as "this frame has no future value," and the gap between them is where photographers get into trouble.

Start with the shape of the decision rather than the storage bill. The two outcomes are not symmetrical:

• Keeping a worthless frame costs a known, small, recurring amount. You can price it this afternoon, and you can reverse it any time.
• Removing a frame you later need costs an unknown amount, you find out about it months later, usually from a client, and there is no version of that day where you get it back.

When one side of a decision is reversible and cheap and the other is permanent and unpriceable, the default is the reversible one. That is not sentimentality, it is just how you handle a bet where you cannot see the payoff yet.

The case for why unpicked frames earn their keep, the client who asks in March, the album that needs one more horizontal, is made in full in what to do with the photos you don't pick. This article is the policy that follows from it: what the exception looks like, and how a file qualifies for it.

There are three kinds of rejected frame, and only one is a candidate

The mistake underneath most bad archive decisions is treating every unpicked file as one category. Sort them once, on a Tuesday, and the policy writes itself.

Tier 3 is the one people get wrong in both directions. A technically imperfect frame of a moment that happened once can be worth more than a flawless duplicate of a posed portrait, and it is worth more precisely because you cannot go back. Soft focus on a grandfather who is no longer here is still a photograph of a grandfather. Judge tier 3 on what is in the frame, never on the score a tool gave it.

Tier 1 is genuinely small. On most shoots it is a few dozen frames out of thousands, which is worth knowing before you spend an evening on it. If your tier 1 pile is enormous, that is a shooting pattern telling you something, and it is cheaper to fix at the camera than in the archive.

What keeping costs, honestly

Keep is the default, but a default you have never priced is a hope. Do the arithmetic once with your own files, because sensor resolution and compression move it enormously.

You need three numbers: the size of one of your own RAW files, the frames you did not pick on a typical job, and the number of copies you keep. A wedding runs roughly 2,000 to 4,000 RAW frames with 400 to 800 delivered, which leaves well over a thousand unpicked frames per job, and each one is stored as many times as your backup rule says. The full chain, frames times copies times years, is worked through in the storage cost of overshooting.

One published rate to anchor on: Backblaze lists B2 cloud storage starting at $6.95 per TB per month, with the first 10 GB free. Multiply your own gigabytes per job by that and you get the monthly cost of one off site copy of one wedding. For most photographers the per job answer lands somewhere near the price of a coffee, set against The Knot's 2025 average of $3,000 for a US wedding photographer.

That is the honest version of the tradeoff. Per job, storage almost never justifies a permanent decision. Across twenty jobs a year for five years it becomes a real line item, which is why the tiers exist: you are not choosing between keeping everything and keeping nothing, you are choosing where the expensive redundant copies go.

Four gates before a single file goes anywhere

Tier 1 is eligible, not condemned. A file only becomes actionable when all four of these are true, and if you cannot say yes to all four out loud, the answer is not yet.

1. Two verified copies exist, on different media, one of them off site, and verified means checksum verified rather than "it looked like it copied." The structure is in the 3-2-1 backup workflow.
2. The gallery is delivered and accepted, the exports open cleanly, and the client review window has passed. Nothing is touched while a job is still live.
3. The contract allows it. Your retention window, whatever you promised in writing, and any commercial terms that override your standard practice. The clause wording is in the photography contract guide.
4. It is a scheduled review. A calendar date, out of season, with a list. Not a Thursday when a drive filled up. Storage pressure is a reason to plan, never a reason to make something permanent in a hurry.

The pass itself is short. Filter to tier 1 only, look at them at a reasonable size rather than as thumbnails, act on that filtered set alone, then write the date and the policy you applied into the job notes. The note matters more than it sounds: in two years it is the difference between "we retain originals for eighteen months" and a guess.

One useful halfway house for jobs you feel uneasy about: keep a low resolution proof set or contact sheet of what you removed. It tells you what existed without carrying the RAW weight. It is not a substitute for keeping a unique original, and it should never be used as one.

A workflow that only marks photos makes this question much smaller

Most of the anxiety in this topic comes from workflows where the first pass is destructive. If rejecting a frame moves it into a Rejects folder, or worse empties it, then every tired judgment at 1 AM is a permanent one, and you are forced to be careful at exactly the hour you are least able to be.

Split the two actions and the problem mostly dissolves. Marking is free, reversible, and safe to do while exhausted. Removing is a separate, scheduled, gated act performed on a filtered set months later. Every serious tool supports this split:

• Lightroom Classic reject flags are metadata until you explicitly act on them, and Adobe's Assisted Culling, currently labeled early access, scores subject focus, eye focus and eyes open, and flags exposure problems and misfires. Adobe states it is optimized for portraits and headshots. Treat the scores as a first sort of your tier 1 pile, not as an instruction.
• Photo Mechanic color classes and ratings do the same job at speed, which is the whole reason people ingest through it.
• Kepla picks your best shots and hands you a shortlist. It never deletes, moves or renames a single file. It only marks which photos it picked, and anything it did not pick is one tap away. The apps for iPhone, iPad and Mac are still being built and we will keep saying so until they ship. The booking page is live and free today.

That is also why doing a first pass on a phone is safe rather than reckless: you are approving a shortlist, not authorizing a purge, so a mis-swipe costs you a tap. If you find yourself second guessing every call, the problem is usually the workflow rather than your eye, and rejecting photos without second guessing covers the fix. Near identical frames, the ones that actually bloat an archive, are handled separately in duplicate photo cleanup.

When keeping is the wrong answer

There are real cases where the default flips, and they have nothing to do with running out of drive space.

The contract says so. Commercial, agency and editorial work can carry terms requiring source files to be destroyed on a schedule, or licensed images to exist only in delivered form. Follow the agreement, not your wedding habit, and never assume one set of terms applies to the other kind of client.

Data you should not be holding. Keeping files longer means keeping everything in them longer: children, the inside of somebody's home, medical or religious detail, a workplace with security concerns, unreleased product. Responsible retention is part of the policy, not a separate topic, and "I forgot that drive existed" is the failure mode to design against.

When you do act on either of these, document what was removed and from which systems, and mean all of them: the working drive, the archive, the off site copy, the old travel SSD in the bag. A deletion that leaves a forgotten copy behind gives you the risk of both policies and the benefit of neither.

There is also a softer failure worth naming. An archive you cannot search is not an archive, it is a storage bill. If you cannot find one specific moment from a 2022 job in a few minutes, fix the naming and folder structure before you buy another drive, as in the RAW file management guide.

The five ways this goes wrong

Every one of these is ordinary, and every one of them is avoidable with a written policy and a calendar entry.

• Acting during the cull. The first pass is where you are fastest, most tired and least reliable. Mark now, act in a scheduled review, never in the same session.
• Treating one drive as an archive. A single copy in a single building is a story about a fire, not a policy.
• Removing before exports are verified. A gallery that uploaded is not a gallery that is correct. Open the exports.
• Promising forever without funding it. If your contract implies permanent access, price it. Say what you actually guarantee and match it in practice.
• Keeping everything and never testing a restore. Once a year, pull a random old job back from the backup. A copy you have never restored is a belief, not a backup.

Write the policy down in one paragraph, put the review on the calendar twice a year, and the midnight version of this question stops occurring. Keep is the default. The exception is small, well defined, and you should have to walk through four gates to reach it.

FAQ