PXPixelConvert
PixelConvert menu
← All guides

Reference guide · cited sources

When Not to Convert: Keeping Originals That Matter

Every guide on this site ends with some version of the same sentence: keep the original. It is worth explaining why, because the advice sounds like fussiness and is actually the one habit that prevents the mistakes you cannot undo.

By Prashantkumar Kishanrao Sundge · Published · Reviewed

What this guide establishes

  • Keep a master and generate derivatives from it. Never edit or overwrite the master.
  • Lossy edits compound. Each save of a JPG discards more, and the loss is permanent at every step.
  • The expensive mistake is rarely one bad conversion — it is replacing an original with a copy made for one purpose.
  • Storage is cheap; rescanning, reshooting, and re-obtaining are expensive or impossible.
  • An archive you cannot search is not much better than no archive. Naming and structure matter as much as the files.

The asymmetry that makes this worth doing

Keeping an original costs disk space, which is cheap and getting cheaper. Losing an original costs whatever it would take to produce it again — which for a photograph of an event is infinite, for a scan of a document now filed away is a day's work, and for a design file from a contractor who has moved on is a new commission.

That asymmetry is the whole argument. The downside of keeping too much is a slightly fuller drive. The downside of keeping too little is occasionally catastrophic and always irritating. When the costs are that lopsided, the habit should default to keeping.

It also removes the need to predict the future. You do not have to know today whether you will want a larger print, a different crop, a version with the metadata intact, or the file in a format that does not exist yet. A master keeps every option open; a derivative has already spent most of them.

Why derivatives cannot substitute for masters

A derivative is built for one destination and carries that destination's compromises permanently. A photograph prepared for an upload form has been resized to that form's limit, compressed to fit a byte ceiling, stripped of its metadata, and possibly cropped to an exact aspect ratio. Every one of those is a decision made for one purpose.

Use that file for a different purpose and the compromises come with it. The image that was prepared to satisfy a 200 KB limit is not the one to send to a printer. The square crop made for a profile picture is not the one to use as a banner.

Lossy formats compound this. Each JPEG save discards information and the loss is permanent, so a file that has been opened, adjusted, and re-saved several times is measurably worse than the original with no way back. Editing a master and exporting fresh derivatives means compression happens once, not once per edit.

And metadata, once removed, is gone. Capture settings, timestamps, and embedded copyright assertions cannot be reconstructed from the pixels.

What makes a good master

The best master is whatever came out of the device, unmodified. A camera's original file, the scanner's output at full resolution, the design application's own project file. These contain the most information and were not made for any particular downstream use.

Where you have a choice of format, prefer lossless and well-documented. TIFF and PNG for raster images, the application's native format for editable work, and a widely supported container rather than a proprietary one where the option exists. Preservation guidance consistently favours formats that are openly specified and broadly implemented, because those are the ones still readable in twenty years.

Resolution should be the highest you have. Downscaling later is trivial and lossless in effect; upscaling recovers nothing.

Keep metadata in the master even when you strip it from everything you share. It is the only record of when and how the file was made, and it cannot be recreated.

One caveat worth stating: a master does not have to be enormous for everything. A snapshot of a receipt does not need archival treatment. Reserve the discipline for material that would actually be painful to lose, or you will abandon it.

A workable structure

The simplest arrangement that works is two locations: originals, and everything generated from them. Never edit inside the originals folder. Anything in the derivatives folder is disposable by definition, which means you can delete it freely without deciding whether it matters.

Name files so that they sort usefully and can be found. Dates in year-month-day order sort chronologically in any file listing, which is why that ordering is worth adopting even though it reads oddly at first. Add a short description in words a future search might use — the project, the subject, the document type.

Avoid names that depend on memory. A folder of files called IMG_4471 through IMG_4620 is not an archive; it is a pile. Ten minutes of naming at the point of filing saves considerably more later, and it is the step people skip.

Record what you did when it is not obvious. A short note alongside a set of scans saying what the originals were, when they were scanned, and at what settings takes two minutes and answers the question someone will eventually have.

Storage that survives

A single copy is not an archive. Drives fail, accounts are lost, devices are stolen, and files are deleted by accident — usually the accident, in practice, rather than the dramatic failure.

The commonly cited rule is three copies, on two different kinds of storage, with one of them somewhere else. The reasoning is that each part covers a different failure: the second copy covers hardware failure, the different medium covers a fault affecting one technology or one device, and the offsite copy covers fire, theft, and flood.

Cloud storage counts as the offsite copy for most people and is the easiest part of this to arrange. It is not a substitute for the local copies, because an account suspension, a billing failure, or a synchronisation error that propagates a deletion will take it with everything else.

Synchronisation is not backup. A folder that mirrors changes everywhere will faithfully mirror a deletion or a corruption. Backups that keep previous versions are what protect against mistakes, which are more common than disasters.

Check your backups occasionally by actually restoring something. An untested backup is a belief, not a safeguard, and the failure mode is discovering the problem at the moment you need it.

When conversion is the wrong instinct

Do not convert an archive to save space. Converting a library of camera originals to smaller files trades something irreplaceable for storage that costs very little. If space is genuinely tight, buy more or move the archive to cheaper storage.

Do not convert to a newer format for its own sake. A format migration is worth doing when the old one is genuinely at risk of becoming unreadable, which is rare for the widely used ones and slow when it happens. Converting because a format is fashionable introduces a lossy generation for no benefit.

Do not normalise everything to one format. The best master is usually the file you already have, and forcing a camera original or a design file into a common raster format discards structure that cannot be rebuilt.

Do not delete a source after a successful conversion. A download completing is not verification. Open the output, check it thoroughly, and keep the source regardless if it is the only copy of something.

The general principle: convert to create something, not to replace something. A derivative is an addition to your archive, never a substitute for what it was made from.

How this guide was written

This is a reference guide. It explains published specifications, platform rules, and format behavior, and every factual claim is attributed to the sources listed below. It does not report an in-house PixelConvert measurement, and no result here should be read as one.

Read how PixelConvert separates measured and reference guides →

Limitations

  • This guide describes general preservation and file-management practice with citations; it reports no in-house PixelConvert measurement.
  • Backup and retention requirements for regulated or legally significant records are set by the applicable rules in a given jurisdiction and are outside its scope.
  • PixelConvert creates derivatives and does not store or manage user files; any archive discipline is the reader's own to maintain.

Frequently asked questions

Why does every guide tell me to keep the original?
Because the mistakes that cannot be undone almost all involve replacing an original with a derivative. Keeping it costs disk space; losing it costs whatever it would take to produce again, which is sometimes impossible.
What makes a good archival master?
Whatever came out of the device, unmodified, at the highest resolution you have, with metadata intact. Where you choose a format, prefer lossless and openly specified ones such as TIFF or PNG over proprietary or lossy alternatives.
Can I convert my photo archive to smaller files to save space?
You can, but it trades something irreplaceable for storage that costs very little. If space is tight, add storage or move the archive somewhere cheaper rather than degrading the originals.
Is cloud sync the same as a backup?
No. Synchronisation mirrors changes, including deletions and corruption. Backups that retain previous versions are what protect against mistakes, which are far more common than hardware disasters.
How many copies should I keep?
The commonly cited rule is three copies on two kinds of storage with one offsite. Each part covers a different failure: hardware failure, a fault affecting one technology, and physical loss of a location.
Should I migrate my files to newer formats?
Only when the current format is genuinely at risk of becoming unreadable, which is rare and slow for widely used formats. Converting for fashion introduces a lossy generation for no benefit.

References