The dates on your photos are the one thing you cannot fix after a bad import.
Every other loss from a migration gone wrong is recoverable. Missing captions can be rewritten. Albums can be rebuilt. Shares can be resent. But if your daughter’s first birthday photos arrive in your new library tagged as “September 2026” instead of “June 2022,” that date is gone. The only way to get it back is to redo the entire export from scratch.
This is the failure that fills Google Photos migration threads, and it is almost never mentioned in the guides that tell you to simply “download via Takeout and upload elsewhere.” The download step is manageable once you know about the zip archive limits. The date problem is different. It is a structural issue with how Google formats its exports, and it catches people who follow otherwise sensible instructions.
Here is the problem, the cause, and the fix.
What Google Takeout actually exports
When you request your Google Photos data through Google Takeout, you get a set of zip archives. The number depends on the size of your library: a 50GB collection typically generates somewhere between 10 and 25 zip files, each capped at 2GB by default.
Inside each archive is a folder of images. And alongside each image, there is a matching .json sidecar file. A photo named IMG_4821.jpg will have a companion file named IMG_4821.jpg.json.
That JSON file is important. It holds: - The date and time the photo was taken - GPS coordinates, if location history was enabled when the photo was taken - Any caption or description you added in Google Photos - Whether the photo was starred
The crucial point: the .jpg file itself may not carry accurate date information in its EXIF data. Google does not always update the DateTimeOriginal field embedded in the image. The JSON is authoritative. The EXIF is not.
The complete guide to downloading your full Google Photos library without hitting download limits covers the archive mechanics in full, including what happens when a download gets interrupted on a large library.
Why dates disappear on import
Most photo services, operating system apps, and import tools read the EXIF data embedded in the image file. They do not look for a matching .json sidecar. When a service opens IMG_4821.jpg and finds no reliable DateTimeOriginal EXIF field, or finds one that says the file was created last Tuesday when you ran the export, that is the date it uses.
Your photos arrive sorted by export date rather than by when the moment actually happened. A library spanning twelve years lands as a single undifferentiated batch, ordered by the week you finally decided to leave Google Photos.
A family with 14,000 photos described exactly this in a r/googlephotos thread. They had exported correctly, uploaded to iCloud, and found their library in complete chronological disorder. A 2010 camping trip sat next to photos from 2024. Baby photos from 2018 were scattered throughout photos from last month. The JSON files were all there in the export folders. No import tool had touched them.
This is the specific failure that is almost completely absent from migration guides and almost universal in migration experiences.
How to fix it before you import
The solution is to write the correct dates from the JSON sidecar files into the EXIF of each image before you import anywhere. Once the EXIF is accurate, any service or app will read it correctly.
Using exiftool (command line, Windows/Mac/Linux)
exiftool is the standard tool for this. It is free, actively maintained, and handles the Google Takeout JSON format. After installing it, run this command on an unzipped Takeout folder:
exiftool -r -d %s -tagsfromfile "%d/%F.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -ext jpg /path/to/your/takeout-folder
This tells exiftool to find the matching JSON file for each .jpg, read the photoTakenTime.timestamp field, and write it as DateTimeOriginal in the image EXIF. The -r flag processes subfolders recursively.
Run this on a test folder of 20 photos before touching your full library. Import those 20 to wherever you are going and confirm the dates appear correctly. If they do, process the rest. If something is off, fix the command on 20 photos rather than on 14,000.
Using a GUI alternative
If you would rather not use the command line, there are GUI tools that wrap exiftool’s functionality: jExifToolGUI on Windows and ExifTool GUI for Mac. The interface is different but the underlying operation is the same. Look for an option that reads Google Takeout JSON files and writes DateTimeOriginal.
Videos
The same sidecar issue affects videos. Each .mp4 or .mov gets a matching .json file. One additional wrinkle: if the original video filename is long, Google sometimes truncates the JSON filename. Exiftool handles this in most cases, but if you notice videos with incorrect dates after processing, check whether their JSON files have truncated names.
For Android users: a note on backup going forward
If you are leaving Google Photos and use Android, turning off the Google Photos backup toggle does not always stop uploads cleanly. You may need to change the backup destination in your phone’s settings as well. How to back up your Android photos without giving them to Google covers the setup for both Android and iPhone – including what changes to make so new photos go to your new home automatically rather than continuing to queue for Google.
If the reason you are moving is what Google does with your library in the background, does Google Photos scan your photos gives a direct answer to what their current policy permits and what it means for your uploaded files.
Checking that dates survived
After running your test batch through exiftool and importing the 20 photos, check three things:
- Correct years. A photo from 2015 should show 2015, not 2026. Check the oldest photos in your test batch specifically.
- Correct order. Photos should sort chronologically by when they were taken, not by when you uploaded them.
- GPS data. If location history was enabled, the location should appear on a map in services that support it.
If any of these are wrong, do not process your full library. The most common cause is exiftool not finding the JSON sidecar, usually because of a path issue in the command. Try running exiftool with a single image and its JSON file in the same folder to confirm it works, then adjust the paths for your Takeout folder structure.
What to look for in a destination service
Once your files are clean and dates are set correctly, the question is where to take them.
Are originals preserved? Some services store a compressed copy and discard the original file. If you shot at full resolution and want those full-resolution files in ten years, confirm the destination service keeps what you upload rather than replacing it with a smaller version.
Can your family actually open it? This is where most privacy-respecting alternatives fall down in practice. Services with strong credentials for user privacy often require everyone you share with to create an account or install an app before they can see anything. That is a real barrier when you share with grandparents or relatives who will not troubleshoot an app just to open a photo link. The best alternatives to Google Photos in 2026 covers where each option stands on this specific point.
Is the pricing stable? Storage subscriptions that start at a low price and increase over time are a meaningful cost over a decade of family photos. A flat yearly fee is easier to plan around.
Does the service answer specifically what it does with your files? Vague reassurances about “privacy” and “security” are not useful. The useful answer is a list of concrete behaviours: whether the service scans uploaded photos, whether it builds ad profiles, whether it sells data to third parties, and whether originals are kept intact. What Google’s privacy policy actually says about your photos is worth reading if you have not read it recently – the specific language has practical implications.
If you are ready to compare options, the Google Photos alternative page covers what Yogile offers for this use case alongside what the main alternatives do.
How Yogile handles imports
Yogile keeps photos at original resolution. When you upload photos with DateTimeOriginal correctly set in the EXIF after the exiftool step, Yogile reads that date and sorts your library chronologically.
A practical test: a family export of 1,847 Google Photos, processed through exiftool to restore dates, uploaded to Yogile. The library sorted correctly from 2009 through 2025. The oldest photos – a 2009 birthday party shot on a Canon DSLR – showed the correct year and position in the timeline. No manual correction after the EXIF step.
Photos on Yogile are private by default. Nothing is visible to anyone until you create a share link. You can add a password to an album if you want an extra layer of control over who can view or contribute. No AI scanning of uploads. No advertising profiles built from your photo library.
For families, the practical detail that matters most: guests can view and contribute to shared albums without installing an app or creating an account. Share a link with your mother-in-law and she opens the album in her browser with no setup. That covers the problem that causes most family photo libraries to stop being shared in practice.
Premium costs $44.99 per year for unlimited photo storage (video storage is generous) and includes an additional backup of your original-quality photos. For a more complete picture of what secure photo storage actually means for ordinary family photos – beyond the marketing language – that page covers the concrete product behaviours in detail.
Create a free Yogile album, import a folder of your test photos after the exiftool step, and check that the dates sort correctly. There is nothing to install, and you will know within a few minutes whether it works for your library.
The one step worth doing carefully
The export and the date-fix are worth doing slowly on a test batch before you process your full library. Everything else in a migration is fast. Albums take minutes to create. Share links take seconds.
The only unrecoverable mistake in a photo migration is arriving at your destination with the wrong timestamps. The photos of people who have since passed, the first hours with a newborn, the places you will not go back to – those deserve the extra thirty minutes on a test batch before you run the full command.
Test on twenty photos. Check the dates. Process the rest.