How to Date and Organize Scanned Family Photos

PDR runs on Windows. Any Mac, iPhone or web steps below are only for getting your photos out first — you then bring the exported folder into Photo Date Rescue on your Windows PC.

Why the scan date is not the photo date

When a flatbed or sheet-fed scanner writes a file, the timestamp it writes is the moment the glass lit up. A print taken in June 1994 and scanned last Tuesday arrives on your PC as a file dated last Tuesday. Nothing in the file disagrees, so any program that sorts by date puts your 1994 print at the front of this year.

PDR catches a good part of this. Many scanners and all-in-one printers write their own make and model into the image’s EXIF, and when PDR sees one it treats that timestamp as the scan time rather than the photograph’s date — the photo is marked for review instead of being filed under the week you scanned it. Where the scanner left no make and model, there is nothing to recognise, and the date stays as unreliable as the file makes it look.

This is the part worth being clear about before you start: digitizing a print creates a new file, and a new file does not carry the old date. Everything below is about what evidence is left, and what to do with the photos where none of it survives.

---

Exact, approximate and unknown dates

PDR sorts every photo it reads into one of three outcomes, and each corrected copy carries a suffix that says which:

• _CF — confirmed. A trustworthy source held a full capture date. For a scan this normally means you put the date in the file’s own name.
• _RC — recovered. A date was found in a weaker source, such as the filename pattern, and is worth reviewing.
• _MK — marked. No source held a capture date, or the date on offer was the scanner’s. The file’s own timestamp is used so the copy still has one, and the suffix tells you not to trust it.

For a shoebox of undated prints, most of the library comes back marked. That is the honest outcome, and it is more useful than it sounds: the marked photos are the ones gathered together for you to work through, rather than being scattered through a timeline under a date nobody chose.

There is no fourth outcome for “sometime in the 1970s”. PDR stores a date or it marks the photo; it has no way to hold a year on its own, and it will not invent a day and month to fill the gap. A placeholder day would look exactly like a real one six months later, and that is a worse archive than an honest blank.

---

Evidence you can use without pretending to know more

The single thing that turns an undated scan into a dated one is the file’s own name. PDR reads YYYY-MM-DD and YYYYMMDD out of a filename — a full year, month and day — and nothing shorter. 1994-06-15_Prints_001.jpg works. Prints_1990s_001.jpg gives it nothing to read.

So the evidence worth collecting is the evidence that can become a full date:

• A date written or stamped on the back of the print, or in the album margin. Photo-lab date stamps on the front of a print count too.
• A processing date printed on the edge of a negative or the mount of a slide.
• A date a relative is confident about for a specific, dateable occasion — a wedding, a christening, a named holiday.

Where you have one of those, rename that file before the run and it comes back confirmed. Where you do not, leave the name alone and let the photo come back marked. Guessing a day so that the file sorts nicely converts a known unknown into a wrong fact, and there is no way to tell them apart afterwards.

Three things that feel like evidence, and are not:

• The folder a photo sits in. PDR does not read it. A folder called 1978 or Scans_1970s changes nothing about the date PDR works out.
• The order the photos were scanned in. Position in a batch, a folder or a reel is never treated as evidence of when a photograph was taken.
• What the picture shows. PDR does not estimate a date from clothing, cars, hairstyles or anything else in the image.

---

Batching photographs from the same event

When a run of prints obviously belongs together — one roll, one wedding, one holiday — and you know the date of the event, the batch is worth handling as a batch. Rename the whole run to the event’s date before the run:

1994-06-15_Wedding_001.jpg
1994-06-15_Wedding_002.jpg
1994-06-15_Wedding_003.jpg

All three come back confirmed on the same day, which is exactly as precise as the evidence actually is — you know the day, not the minute.

Where you do not know the event’s date, batching still helps you, but it does not help PDR. Scanning an album page by page, or keeping a reel in order, preserves a sequence that matters to you; PDR will not read that sequence and will not use it to date anything. Scan pages whole if the album’s order matters, because that scan is the only place the order is kept.

---

Keeping the original scans

PDR never writes to the files you give it. It reads your scans and writes corrected copies into a new folder, so the scan you made from the print stays exactly as your scanner produced it. That matters more for scans than for anything else in a library: the print can be re-scanned, but the negative may be gone, and a scan you have already thrown away is gone with it.

Two things worth doing once, at the start:

• Scan at 600 DPI for prints and 2400–4000 DPI for negatives and slides, and save as TIFF or high-quality JPEG. Detail not captured at scan time cannot be added later.
• Keep the raw scans on their own drive, separate from the corrected library, and leave them alone. Re-scanning a collection because the first pass was over-written is the one cost in this whole process you cannot recover from.

A note on duplicates, because scan projects produce them: PDR compares a SHA-256 hash of each file’s contents, so it skips copies that are byte-for-byte identical — the same file copied twice. It does not compare images for visual similarity, so the same print scanned twice, or scanned at two different resolutions, is two different files to PDR and both will come through.

---

What PDR cannot infer automatically

Stated plainly, so you can plan around it rather than discover it:

• It cannot date a photograph from what is in the picture. No clothing, no car models, no hairstyles, no scene analysis.
• It cannot read a folder name. Era-labelled folders are for you.
• It cannot use order as evidence. Not batch order, not album order, not reel order.
• It cannot store a year without a day and month. “About 1975” is not a date PDR can hold, and it will not invent one.
• It cannot recognise a scanner that left no make and model in the EXIF. The demotion to marked depends on that EXIF being there.
• It cannot read a separate .xmp file for a date. Those are opened only for face regions.

Everything on that list is work only a person can do, from paper, memory or a relative. PDR’s job is to make sure that work is aimed at the right photos — the marked ones — and that the dates you are sure of survive into the library intact.

---

Which scanning method suits your material

---

---

Related Guides

Continue learning with these related guides:

• From the blog: how to fix wrong photo dates on Windows
• Fix photo dates from Google Photos, iCloud, and cloud services
• Fix photo dates from WhatsApp, Messenger, and social app exports
• Recover photos from phones, cameras, and SD cards
• Recommended tools for managing your restored photo library