How to Fix Wrong Dates and GPS Locations in Your Photo Metadata

Start with a copy and a known correction

A wrong date in a photo library does not necessarily mean the embedded capture date is wrong. The library may sort by a filesystem timestamp, an import date, or a value saved only in its database. A location shown by a gallery need not be embedded GPS.

This tutorial describes the current JPEG EXIF Editor, based on its implementation. It handles one JPEG at a time, not HEIC, PNG, WebP, TIFF, or RAW editing. Renaming an extension does not convert a file. Keep the original and work on a separate copy. The examples below are illustrative, not results from a tested camera file.

1. Identify which value is wrong

Open the copy in the metadata viewer. Inspect DateTime and GPS, then export JSON so you can compare the fields returned before and after editing. A missing field can mean absent data or a reader limitation; an empty report is not a complete-file privacy certificate.

Value	Meaning	Editor limitation
DateTimeOriginal	Recorded capture time, normally a local wall-clock string such as 2026:10:24 14:30:00	Editable, but not independently verified
OffsetTimeOriginal	Separate UTC offset, if recorded	No control to add or correct it
CreateDate / DateTimeDigitized, ModifyDate	Other embedded dates that may differ from capture time	Not exposed as editable fields
Filesystem modified time	A disk file property, not the embedded capture-date string	Not set by this editor; downloading creates a new local file
GPS latitude/longitude	Coordinates recorded in metadata	Editable as signed decimal degrees

The other editable fields are Make, Model, ImageDescription, Artist, and Copyright. There is no Orientation, subsecond, or batch time-shift control. Editing DateTimeOriginal does not synchronize other date fields or a cloud library’s database.

2. Correct a capture time you can establish

1. Open the editor and select the working JPEG.
2. Record the existing capture-date value. Compare it with independent evidence, such as a contemporaneous clock photo or event record.
3. Enter a valid date and time in YYYY:MM:DD HH:MM:SS form, for example 2026:10:24 14:30:00. Use a space between date and time. Check month, day, and leap-year validity yourself; the text field is not a calendar validator.
4. Leave unrelated fields unchanged. Apply changes, then download the new edited_ copy. Applying without downloading does not replace the source file.
5. Reopen that downloaded JPEG in the viewer and compare the capture-date field with your intended value.

For an illustrative clock error, if the recorded time is 2026:10:24 00:30:00 and reliable evidence shows the camera was two hours fast, the correction is 2026:10:23 22:30:00. Check the date rollover, not just the hour. The editor does not calculate or apply this shift to a folder.

A clock correction is not a timezone conversion

DateTimeOriginal alone does not establish a UTC instant. Do not append Z or +08:00 to this field: the current writer normalizes hyphens and takes the first 19 characters; it does not write a timezone offset. An existing offset can remain inconsistent after a clock correction. To repair offsets, subseconds, or linked date fields, use a tool that explicitly supports those tags and verify them separately.

If the date is missing, first look for an original backup or trustworthy accompanying records. A filename or disk modified time is only a clue, not proof of capture time. For scans, distinguish the scanning date from the historical scene date. Do not invent an exact timestamp from a remembered year; keep uncertainty in a separate note rather than presenting an estimate as recovered fact.

3. Correct coordinates or remove EXIF GPS selectively

For a known location, enter both latitude and longitude as decimal numbers with a dot, without degree symbols or N/E/S/W letters. Latitude must be between -90 and 90; longitude between -180 and 180. Negative values mean south or west. The illustrative pair -12.5, 130.25 demonstrates syntax only, not a suggested replacement location. The editor writes coordinate references from the signs.

Changing coordinates does not update altitude, GPS date/time, direction, or duplicate location fields in XMP/IPTC. Check these for inconsistency. Do not substitute an invented nearby coordinate when the actual location is unknown.

To remove EXIF GPS through selective editing:

1. Use the editor’s GPS-removal button. It clears the EXIF GPS directory when changes are applied.
2. Apply changes and download the copy.
3. Reopen the copy and inspect GPS and other returned location-related fields. Clearing just the two coordinate inputs is different: other EXIF GPS entries may remain.

This is not a guarantee that every location clue in every metadata family is removed. The editor rewrites EXIF through a library; do not assume all proprietary or malformed metadata survives unchanged. Compare important fields and retain the original.

The separate metadata remover is for broader cleaning, not selective GPS editing or date repair. Its canvas-based JPEG export re-encodes the image and can change quality; it does not promise to preserve dates, copyright, or camera settings. Visible addresses and landmarks remain in the pixels.

4. Verify outside the library view

For a second reader, install ExifTool and run these read-only commands on your actual filenames, once for the original and once for the downloaded copy:

exiftool -a -G1 -s "photo.jpg"
exiftool -a -G1 -s "edited_photo.jpg"

The options show duplicate tags, their groups, and tag names; there are no write assignments or deletion options. Compare DateTimeOriginal, any offset, other embedded dates, and location fields across groups. See the official ExifTool documentation for the reading options.

If embedded values are correct but the library still sorts incorrectly, check its sort mode and whether it needs a metadata refresh or a new import. Do not repeatedly change the capture date to compensate for an unexplained display rule.

Use the metadata-check lab to explore the site’s demonstration workflow before working on personal photos. A synthetic demonstration does not validate every camera or JPEG. Success means the downloaded copy contains the intended supported values, with remaining limitations understood, not that a lost date has been recovered or every application will sort identically.