Restoring capture dates and filenames

How Photo Date Rescue works out when a photo was taken — and, just as plainly, the cases where it cannot.

Applies to: Photo Date Rescue for Windows, version 3.0.4. Last verified: 28 July 2026. Every statement on this page was checked against the shipping 3.0.4 source, not against our own marketing copy. If you are on an older or newer version, the behavior may differ — check What’s new for changes.

This page is the reference we cite from our comparison table. Each capability below has its own permanent link, so a claim about PDR can always be traced to the paragraph that supports it. Where the answer is “no” or “only partly”, this page says so in the same words the comparison uses.

One distinction runs through everything below, and it is worth getting straight first:

A Fix run reads your source folders, works out the right date for each photo, and writes corrected copies to a destination you choose. This is the main pipeline and it never writes to your sources.
Needs Dates is where photos land when a Fix run could not establish a date confidently. You can set the date yourself there. That is a change to your library record, not to the file — the photo on disk is not rewritten or renamed.

At a glance

Capability	In 3.0.4
Works out the correct date for each photo itself, rather than you supplying or calculating it	Yes. Anything it cannot settle is set aside for you.
Reads Google Takeout and phone export bundles and uses their date records	Yes, for Google Takeout
Uses sidecar and JSON metadata when the file itself has no date	Google JSON yes. Third-party XMP sidecars, no.
Writes results to a copy, leaving the original files unmodified	Yes, for every Fix run
Undoes a batch after it has been applied	No. Nothing you started with is changed, so the route back is to discard the output and run again.
Shows what it intends to change, with its reasoning, before committing	Shows the change. Does not show the reasoning.
Handles thousands of files in one run without manual steps	Yes. The free trial has a lifetime file limit.
Builds filenames from capture date, camera and sequence	Date yes. Camera and sequence, no.
Matches photos to their date records when an export is split across several archives	Yes, for every part you add.
Gathers the photos it could not date confidently in one place for you to finish	Yes, sorted into three groups.
Tells you which copy it kept when it skips a duplicate	Only partly. Listed in the report, silent at the time.
Lets you choose whether the result is filed by year, by month or by day	Yes. All three, chosen before the run.
Brings photos exported from iPhoto or Apple Photos back correctly dated	Yes for the dates. No importer, so nothing else.

Working out the date without being told it

You never type a date and you never work out an offset. PDR puts every photo through a ranked chain of evidence and takes the answer from the first source that can give one, in this order:

The Google Takeout JSON record shipped beside the image, including records recovered from the other numbered zip parts.
The EXIF capture date embedded in the file, for JPEG and TIFF.
An XMP block read straight out of the file. This one is not tied to a format, so it is what answers for HEIC, AVIF and similar containers.
Date patterns in the filename, for the many phones and cameras that put the date there.
Failing all of those, the file’s own timestamp.

Each answer carries a confidence with it, and the source is recorded against the photo so you can see where its date came from rather than having to trust it.

Two limits worth knowing. The last step in that list is a fallback, not evidence: a file’s timestamp is often the date it was copied rather than the date it was taken, and where PDR has had to use it, it says so. And a photo the chain could not settle confidently is set aside as Marked, for you to answer yourself in Needs Dates. That is the honest half of the automation, but it has a consequence: Needs Dates only offers you the photos PDR flagged. If PDR dated a photo confidently and got it wrong, there is no screen in 3.0.4 where you can correct that one photo by hand — the route back is to change the sources and run the fix again.

See why PDR chose the date it chose

When PDR dates a photo, it has a reason, and this shows you the reason before you run the fix on your own library — so a date you did not expect is something you can explain rather than something you have to trust. Pick one of the four files below and reveal its sources one at a time, numbered 1 to 5, in the order 3.0.4 actually tries them. The four files are made up and none of the dates came off a real photo: they show the shape of an answer, not a prediction of what your library will do.

Illustrative IMG_20190612_101500.jpg unpacked from Takeout/Google Photos/Summer 2019/

Google Takeout JSON record beside the file Answer found A file called IMG_20190612_101500.jpg.json sits beside it, carrying Google’s own record of when the shutter went. The chain takes that and stops.
EXIF capture date inside the file Not reached The chain is ranked, not a vote: it takes the first source that can answer and does not read the ones below it.
XMP block inside the file Not reached Same reason. Nothing here is opened.
Date pattern in the filename Not reached This name does carry 20190612, and it happens to agree — but it was never asked. A lower source is not used to check a higher one.
The file’s own timestamp Not reached The fallback only exists for files where the four above all came back empty.

Confirmed 12 June 2019, 10:15

Written into the copy PDR creates in your chosen destination. The file you pointed it at is read and never written to.

What PDR does not know here: Whether Google’s record is right. PDR is repeating a timestamp somebody else wrote — it can tell you which source won, which is the point of recording it, but it cannot audit it. And if the export is missing its JSON records entirely, this step returns nothing and the file drops to step 2. (PDR does look through the other numbered zip parts for a stray record first, because Google routinely splits a photo from its own record.)

Illustrative DSC_0043.JPG copied straight off a camera card

Google Takeout JSON record beside the file Nothing to read No Takeout export, so there is no JSON record beside it. Nothing failed here — the source simply does not apply to this file.
EXIF capture date inside the file Answer found DateTimeOriginal is still in the file: 3 August 2016, 18:42. The camera wrote that tag at the moment of capture, which is the strongest thing a JPEG carries.
XMP block inside the file Not reached XMP is what usually answers for HEIC, AVIF and similar containers, where EXIF is not the format’s habit. This file answered a step earlier.
Date pattern in the filename Not reached DSC_0043 holds no date in any case. A sequence number is not a date and PDR will not read one as one.
The file’s own timestamp Not reached Never reached.

Confirmed 3 August 2016, 18:42

Written into the copy. Same as every other outcome on this page: the Fix pipeline has no in-place option at all.

What PDR does not know here: Whether the camera’s clock was right. PDR reads what the camera wrote; it cannot check it. A body an hour behind on the day, or still on the date it shipped with, produces a Confirmed date that is confidently wrong — and 3.0.4 has no screen for correcting one confidently-dated photo by hand. The route back is to change the source and run the fix again.

Illustrative IMG-20180714-WA0032.jpg saved out of a chat thread

Google Takeout JSON record beside the file Nothing to read No export bundle, so no record beside it.
EXIF capture date inside the file Nothing to read The app re-encoded the picture when it sent it and dropped the metadata with it. That happened long before the file reached you, and nothing PDR does can put it back.
XMP block inside the file Nothing to read Stripped in the same re-encode.
Date pattern in the filename Answer found IMG-20180714-WA0032 matches the pattern those apps use — IMG or VID, the date, then WA and a counter. PDR reads 14 July 2018 out of it.
The file’s own timestamp Not reached Never reached.

Recovered 14 July 2018, 12:00

Recovered rather than Confirmed, and the gap is deliberate. A filename is a strong hint written by software; it is not a record the camera made at capture. PDR grades it one tier down and stores the source against the photo, so a date worth questioning is visibly one you can question.

What PDR does not know here: The time of day. That name carries a date and no clock, so PDR files it at midday — a placeholder that keeps the photo inside the right day, not a reading of anything. It also cannot tell whether the sender took the photo that day or forwarded something years older: the date in that name is the day it went through the app.

Illustrative scan_final_v2.png in a folder called Nan’s box of prints

Google Takeout JSON record beside the file Nothing to read No export bundle.
EXIF capture date inside the file Nothing to read The scanner wrote no capture tag — and a capture tag on a scan would be the date of the scan anyway, not of the photograph.
XMP block inside the file Nothing to read None present.
Date pattern in the filename No pattern matched scan_final_v2 holds no date. PDR needs four digits that read as a year between 1970 and 2100, and it will not manufacture one out of v2.
The file’s own timestamp Used, as a fallback 9 March 2021 — the day this file was written to this disk. That is a fact about the copy, not about the photograph, and PDR treats it as one.

Marked set aside for Needs Dates

Marked is PDR declining to answer. It does not put 2021 forward as a capture date on the strength of a copy timestamp; it hands the photo to you in Needs Dates instead. That is the honest half of the automation, and it has a cost: Needs Dates only ever offers you the photos PDR flagged.

This is the one place a folder counts. In Needs Dates, PDR offers ranked suggestions drawn from context, and one of them is the median date of the Confirmed and Recovered photos in the same folder. It is the weakest suggestion it makes — ranked below the photos either side of this one in time, below sequential filenames, below a timestamp in the name, below the people in the frame and below GPS. It is a suggestion you accept, not a date PDR applies.

What PDR does not know here: When this was taken. There is no evidence left in the file at all. Everything Needs Dates can offer is inferred from the photos around it, so if this print is the only one of its era in the folder there is nothing to infer from either. Some photos only you can date.

Folder names are not one of the five. A photo sitting in a folder called 2004 Holiday gets nothing from that name: the automatic chain never reads the folder a file is in. Folders come back later and in a much weaker role, as one of the ranked suggestions in Needs Dates, as the fourth example shows.

When two sources disagree there is no argument. The chain is ranked, not a vote. PDR takes the first source that can answer and stops; a lower source never overrules a higher one and is never consulted to check it. That is what makes the outcome predictable, and it is also the failure mode — if the highest-ranked source is wrong, the answer is wrong with it, quietly and at full confidence.

No file carries all five. A JPEG off a camera almost always has EXIF and almost never has a JSON record beside it. A HEIC generally has no EXIF block, which is why XMP is on the list above it in the first place. A PNG off a scanner usually carries neither. The five steps and their order are the same for every file; what differs is how far down the list it has to go.

Reading Google Takeout and phone export bundles

Yes, for Google Takeout. When you export from Google Photos, each image arrives with a small JSON file recording the real capture time. PDR reads those records and uses them as a high-confidence date source, ahead of anything it would otherwise have to guess from.

Two details matter more than they sound. First, Google’s naming of those JSON files is inconsistent, so PDR tries several naming patterns rather than one. Second, a large Takeout export is split into numbered zip parts, and Google frequently puts a photo in one part and its JSON in another. PDR scans the other parts for the matching records before it starts, so a photo in part 007 still finds its date in part 008. Without that, a large export loses dates for no reason the user could ever see.

PDR also restores album names, captions and the original filenames that Google replaced.

The limit

This is Google Takeout specifically. There is no importer for Facebook, Flickr, Amazon Photos or Apple/iCloud export bundles. Photos exported from those services are still processed — PDR falls back to reading the files themselves — but their own metadata records are not parsed.

Using sidecar and JSON metadata

Partly. The JSON half is covered, as described above. The XMP half is not, and the distinction is easy to miss.

PDR reads XMP metadata when it is embedded inside the image file. It does not take dates from a separate .xmp file sitting next to the photo. If you have worked in Lightroom, darktable or Capture One, your corrected dates may live in exactly those separate files, and PDR will not see them. It does open those files, but only to read face regions — never a date.

If that is your situation, the reliable route today is to have your editor write the metadata back into the image files before running PDR.

Writing results to a copy

Yes. Every Fix run is a copy operation. You point PDR at the folders, drives or export archives holding your photos, you choose a separate destination, and PDR writes corrected copies there. The files you pointed it at are read and never written to. This is not a setting that can be switched off — there is no in-place option in the Fix pipeline at all.

Correcting a date by hand afterwards, in Needs Dates, does not change this. That records your answer against the photo in the library; it does not rewrite or rename the file on disk. So no part of restoring a date modifies a file you already had.

Undoing a batch after it has been applied

No. There is no way to undo a completed Fix run from within PDR 3.0.4.

In practice this is far less alarming than it sounds, for the reason set out above: a Fix run writes copies and leaves your sources untouched. Undoing one means deleting the output folder and running again. Nothing you started with is at risk.

We are not going to dress that up as a feature. If you make a poor choice halfway through a 40,000-file run, PDR does not offer a rollback, and a tool that reversed the run as a single action would be better. It is a known gap and it is listed as one below.

Showing what it intends to change before committing

Partly — it shows the change, not the reasoning. Preview Changes lists each photo’s current filename against the proposed one, with a confidence badge, and you can search and filter that list before committing.

Three limits worth knowing

The preview renders the first 100 rows. On a run of thousands you are seeing a sample, not the whole job, and the screen says so: the last line of the list reads “Showing first 100 of N files”, and the tier buttons across the top carry the full counts for the whole run, not for the sample.
It shows a confidence tier, not the individual reason. The exact source that won for a given photo — and PDR records seventeen distinct ones on our own library, down to which part of a split Takeout export supplied the date — is only reported after the run.
You cannot deselect individual rows. The preview is a preview, not a selection step; the only button at the foot of it closes the window.

Known defect: the legend under the preview is not always accurate. The preview prints a key mapping each badge to a kind of evidence. We measured that key against 88,764 files from 88 real runs and it does not hold for the two lower tiers. The key says Recovered means the date came from a filename pattern — 178 of 2,260 recovered files actually got theirs from a preserved file timestamp. It says Fallback means the file’s modification time — 50 of 617 came from EXIF instead, flagged by PDR as a scanner’s clock rather than the photo’s date. Roughly one in twelve of those two tiers is therefore described wrongly by the key beside it. Treat the badge as a confidence level, not as a statement of source, and read the post-run report for the source that actually won.

PDR does hold detailed, human-readable reasoning for date decisions — it will tell you it inferred a date from neighboring photos, a folder’s median, sequential filenames or GPS proximity. That reasoning is real and it is good, and the report you get after a run names the winning source per file and pages through the whole run rather than stopping at a hundred. It is simply not surfaced in the preview, which is where it would be most useful.

Handling thousands of files in one run

Yes. There is no file-count ceiling in the engine. Work is streamed and processed in bounded parallel batches so that a very large run does not exhaust memory, and conversions are handed to a separate long-lived process for the same reason. None of that requires anything from you mid-run. Individual file timeouts fail that one file and let the run continue.

The limit that will actually stop you

The free trial has a lifetime file allowance, and it is checked before a run starts: if the run would take you past it, PDR refuses the whole run rather than processing part of it. Paid licenses have no file limit. Only one Fix run can be active at a time.

Building filenames from capture date, camera and sequence

Partly — the date, but not the camera or a sequence number. PDR names corrected files from the capture date and time, in the form 2019-08-04_14-32-06, with a short suffix recording how confident it is in that date.

It does not put the camera make or model into the filename. PDR reads them, but uses them only to detect scanned photographs. It does not append a user-visible sequence number either; where two photos would land on the same name, PDR resolves the clash internally.

There is no configurable filename template in 3.0.4. If you need Family-Holiday_Canon-EOS-R6_001.jpg, PDR will not produce it.

Exports that arrive split across several archives

Yes. When a Google Photos export is too large for one file, it is broken into numbered parts, and that split pays no attention to keeping a photo together with the small record holding its real date. A photo can sit in part seven while the record that dates it sits in part eight. PDR reads the date records out of every part you give it and keeps them all in one place, so when a photo comes to be processed its record is found regardless of which archive it arrived in. You add the parts one at a time, and after each one PDR offers to take another. See reading Google Takeout exports for what those records contain and what they are used for.

To do it

Add the first part as a source and let the scan finish.
When PDR offers to scan another part, add the next one, and keep going until every numbered part has been added.
Check the totals, choose a destination, and run the Fix.

Limitations

A record in a part you never added cannot be found. This works because you handed PDR the whole export. Leave a part out and the photos whose records were in it fall back to weaker evidence, exactly as if the records had never existed.
Nothing tells you a part is missing. Each scan adds to what is known, so adding a part later does work and does improve the result — but PDR has no way to tell that parts three and nine were never offered to it, and it will not warn you.
The pairing is made on the photo’s filename, with its size and date as a fallback. Renaming files between parts, or unpacking them through a tool that renames on clashes, can defeat the match.

Finishing by hand the photos it could not date confidently

Yes. Everything PDR could not settle confidently is collected into one place rather than scattered through the library for you to hunt down. They are separated into three groups so you know what you are looking at before you start: dates taken from the file’s own timestamp, which may be a real capture date or may be nothing more than when the file was copied; dates that are almost certainly wrong, such as the moment a print was scanned; and files carrying no date anywhere at all. You can select several photos at once and set them together, and there is an undo while you work.

To do it

Open Memories, then Needs dates.
Pick one of the three groups. Working through a group at a time keeps like with like, because the reason a date is doubtful is the same for everything in it.
Select one photo or several, set the date, and apply it. The undo is there if you change your mind.

Limitations

A date with no time is recorded as midday. If you set only a date, PDR fills the time in at noon rather than midnight, so the photo sorts into the middle of its day rather than the start of it. There is no way to record “this day, time unknown”.
The undo lasts for the session only. Close PDR and it is gone. What you set is kept; the ability to step back from it is not.
There is no “apply this to everything that looks like this”. The grouping is by how doubtful the date is, not by camera, by folder or by source, so you cannot say “every photo from this scanner belongs in 1994” and have PDR work out which ones those are.
Only the photos PDR flagged appear here. A photo it dated confidently and got wrong is not in this list — see working out the date.

Knowing which copy was kept when a duplicate is skipped

Only partly, and the gap is in the telling rather than the doing. On a local drive PDR compares the actual contents of files, so a photo that has been copied and renamed several times over the years is recognized as the same photograph rather than guessed at from its name. On network drives, cloud-synced folders and files over 500 MB it falls back to matching on filename and size instead. Duplicates are consolidated as the run goes, which is why you are not stopped and asked the same question several hundred times.

Corrected 30 July 2026, twice. This page said the run’s report “lists each one against the file it was a duplicate of”, and told you to open the report and read that list. The report on screen gives you a count only — it never names the copy that was kept. That pairing is written to PDR_Catalogue.csv in the root of your destination folder instead. This page also presented the content comparison without qualification; the fallback above is real and is not rare.

To do it

Run the Fix as normal. Duplicates are handled without stopping to ask you.
To see which copy was kept, open PDR_Catalogue.csv from the root of your destination folder in a spreadsheet. Skipped files carry a “Retained as:” column naming the copy kept in their place, and a column saying whether the match was on content or on filename and size. The plain-text catalog does not carry this detail.
Your sources are untouched either way, so a decision you disagree with is reversed by changing what you added and running again.

Limitations

The consolidation is silent while it happens. Nothing marks a photo in your source as a duplicate, and nothing appears on screen as they are found. If you never open the catalog, a file simply will not be in the library and you will have no idea why.
Nothing in the app ever names the kept copy. The run report shows a count of duplicates skipped and stops there. The only place the pairing exists is the catalog CSV on disk.
When two copies are equally good, you are not told how the winner was chosen. PDR keeps one and reports which, but the rules behind that choice are not explained anywhere in the product or on this page.
How closely two files are compared is not uniform. Very large files and a setting you can change both affect it. See finding duplicates and duplicates and collisions for where the content comparison gives way to a weaker test.

Choosing whether the result is filed by year, by month or by day

Yes. Before the copy runs, you choose the shape of the finished folders: by year, by year and month, or by year, month and day. Whichever you pick, that is what gets built at the destination, and the choice is remembered so the next run starts where you left off rather than back at the default. See giving the library a structure for how this sits alongside albums.

To do it

Add your sources and let the scan finish.
Choose your destination, then choose the folder depth — year, year and month, or year, month and day.
Run the Fix. The folders are created as the copies are written.

Limitations

There is no preview of the structure before you commit. You choose the depth from its description, not from a sample of what your own collection would look like in it.
Day-level foldering makes a great many small folders. A week away becomes seven folders holding two or three photographs each. On a large collection that is thousands of folders, which is slow to browse and slow for some backup tools to walk.
There is no flat option. Year is the shallowest structure available; you cannot have every corrected file in a single folder.
Changing your mind later means running again to a new destination. Nothing restructures a library that has already been written.

Photos exported from an old iPhoto or Apple Photos library

Yes for the dates. No for anything else. Photos exported out of iPhoto or Apple Photos are ordinary image files carrying their own embedded capture information, and that is exactly what PDR reads. So an old Apple library comes back correctly dated and in the right order, and the years of pictures you thought were stranded are usable again. Be clear about why that works, though: it works because an Apple export preserves the dates inside the files, not because PDR knows anything about Apple.

To do it

Export your photos out of iPhoto or Apple Photos as ordinary image files, keeping the originals rather than edited versions where you are offered the choice.
Add the exported folder to PDR as a source, the same as any other folder.
Choose a destination and run the Fix. Dates are read from the files themselves.
Anything that arrived without embedded capture information lands in Needs dates for you to finish — see finishing by hand.

Limitations

There is no Apple or iCloud importer. PDR does not read Apple’s own metadata files or edit files, and it does not understand the structure of an Apple Photos library. It reads the exported image files and nothing else.
Albums you built in Apple Photos do not come across. Only the photos and their dates do. This is genuinely different from a Google Takeout export, where PDR does read Google’s own records and can rebuild your albums — see reading Google Takeout exports and albums surviving the move. There is no equivalent for Apple and we are not going to imply there is.
A photo exported without its embedded capture information has no Apple-specific fallback. PDR treats it like any other undated file: the filename and the file’s own timestamp are tried, and if neither settles it, the photo goes to Needs dates for you to answer.
The same applies to every other service. Facebook, Flickr and Amazon Photos exports are read as ordinary folders too. Google Takeout is the only export format whose own records PDR parses.

Known gaps in 3.0.4

These are the things we would want to know if we were choosing the software, so they are here rather than buried.

In HEIC, AVIF and similar files, the date is read from XMP but not from EXIF. PDR’s EXIF reader handles JPEG and TIFF. For HEIC and the other container formats it relies on the XMP block instead, which it reads regardless of format. In a controlled test, a container file carrying both an EXIF date and an XMP block was dated correctly and marked Confirmed. The same file with the XMP removed and the EXIF date left in place fell through to the file’s own timestamp instead. So the gap is a file that carries an EXIF capture date and no XMP. We have not yet measured how often that combination occurs in real camera and phone output, so we are not going to tell you it is rare. We are treating it as a defect to close rather than as intended behavior.
Video capture dates are not read from the file. MP4 and MOV files carry a creation time in the container; PDR does not currently read it, and falls back to the filename or the file timestamp.
No undo of a completed run, as described above.
No importer for Facebook, Flickr, Amazon or Apple/iCloud export bundles. Google Takeout is the only export format whose own metadata records PDR parses.
Date reasoning is not shown before you commit, only afterwards.

How to check this page is still true

This page is cited as evidence in a public comparison against other people’s products, so it carries a higher burden than ordinary help text. Everything above was verified against the shipping 3.0.4 build on 28 July 2026 by reading the source, deliberately without trusting our own feature list — a previous audit caught that feature list claiming an importer which does not exist.

If something here does not match what the software does on your machine, that is a fault on our side and we want to hear about it. Please contact support. Tell us the anchor — for example /help/restore#undo — and we will either correct the software or correct the page.