Immich Shows the Wrong Dates After Import (Fix)
Why photos land on the wrong date in Immich, how Immich picks a date from EXIF and sidecars, and how to fix the files before importing.
You set up Immich, uploaded your library, and the timeline is wrong. Thousands of photos are dated the day you imported them. Old holidays sit at the top. Some dates are off by exactly a few hours.
How Immich picks a date
Immich reads each file's metadata and takes the first date it finds in a fixed order. Roughly: an XMP sidecar beside the file if there is one, then EXIF DateTimeOriginal, then the video's CreateDate, then the file's modified date as a last resort.
It reads the file. It does not ask you. So a photo with no EXIF date gets the file date, and the file date is whatever your last copy operation left it as, usually today. /blog/exif-date-taken-vs-file-modified explains the difference.
Immich's own uploaders, the mobile app and the CLI, pass along the file's modified date, so if that is also wrong there is nothing left to save the photo.
The common causes
Google Takeout. The biggest one. Google strips EXIF dates from many photos and puts the real date in a .json sidecar next to the file. Immich does not read Google's .json format. Upload those files directly and every one without EXIF gets the upload date. /blog/google-photos-export-to-immich is the full guide for that case.
Messaging apps. WhatsApp and friends strip EXIF entirely. Those photos have only a file date.
Screenshots and downloads. PNGs and web images rarely have EXIF dates.
Scans. The scanner's date, which is when you scanned, not when the photo was taken.
Time zone shifts. A photo with an EXIF date but no time zone offset is treated as UTC by some paths and local time by others. The date is right, the hour is off. Newer phones write an offset tag and avoid this.
The two ways to fix it
Fix inside Immich. You can select photos in the web UI and edit the date and time, one selection at a time. For a few photos this is fine. For a Takeout export of forty thousand it is not, and the fix lives only in Immich's database. Export the library later and the dates are gone again.
Fix the files first. Write the correct date into each file's EXIF before uploading. Immich reads it, gets it right, and so does every other tool you ever point at those files. This is the durable fix.
immich-go, and when to use it
immich-go is a free command-line uploader that understands Google Takeout. It reads the .json sidecars, matches them to files and sends the correct date to Immich along with the upload. If Immich is your only destination and you are comfortable with a terminal, it is a good tool and it handles albums too.
What it does not do is change the files. The date goes into Immich's database, not into the photo. If you ever migrate again, or point PhotoPrism or Apple Photos at the same files, you start over.
Fixing the files by hand
exiftool can write the Takeout date into EXIF. The command is fiddly because Google's sidecar names do not match the photo names in several ways. There is a worked example at /blog/exiftool-fix-google-takeout-dates.
For photos that have no sidecar and no EXIF but whose file date is right, copy the file date in:
exiftool "-DateTimeOriginal<FileModifyDate" -if 'not $DateTimeOriginal' -r .For a folder where you know the date and nothing else, set it:
exiftool -DateTimeOriginal="2014:08:10 12:00:00" -overwrite_original .Then re-run Immich's metadata extraction job from the admin page, or re-upload, so it reads the new values.
Doing it with the app
Takeout JSON Metadata Fixer prepares a folder that Immich imports cleanly. It writes the real date and GPS into every file, so Immich reads them straight from EXIF.
Feed it a Takeout export, in one zip or many, or any folder. For each photo it takes the date from the .json sidecar, falls back to EXIF, then to the file date, and writes the result into the file's EXIF and its timestamps. GPS goes in the same way. HEIC can be converted to JPG on the way. Photos with no date at all can be given one date and place for the folder.
It also writes a .json sidecar beside each output file if you turn that on. Immich itself does not read those, but immich-go and other importers do, and they keep the metadata readable outside any library. Then upload the output folder with the Immich app, the CLI or an external library. The dates are in the files, so they arrive right the first time.
Offline on macOS, Windows and Linux. Free for 500 photos, $9.99 one-time for unlimited.
Frequently asked questions
I already imported. Do I have to start over?
Not necessarily. Fix the files on disk, then run the "Extract metadata" job for all assets from the Immich admin page. If the files were uploaded rather than in an external library, you need to re-upload the fixed ones and delete the old copies, because Immich keeps its own copy.
Why are some dates off by a few hours?
Time zone. The EXIF date has no offset, and Immich treats it as UTC or as server time depending on version and settings. Newer versions handle this better. Setting the server time zone to match where most photos were taken helps.
Does Immich read Google's .json sidecars now?
Not directly, as of this writing. It reads XMP sidecars. immich-go reads Google's format and converts on the fly. Check the Immich release notes, since this changes.
Will fixing EXIF change the photo quality?
No. Writing EXIF edits a metadata block. The compressed image is not touched.