JPEG, HEIC and HEIF, AVIF, PNG, WebP, TIFF
These formats can all carry an EXIF block and an XMP block, the two places photo apps look first. FixMyTakeout writes the same set into each:
| What | Tags written | Value |
|---|---|---|
| Date | EXIF:DateTimeOriginal, EXIF:CreateDate | Local time in the photo's zone, YYYY:MM:DD HH:MM:SS |
| Offset | EXIF:OffsetTimeOriginal, EXIF:OffsetTimeDigitized | The zone's UTC offset, for example +02:00 |
| Position | EXIF:GPSLatitude with GPSLatitudeRef, EXIF:GPSLongitude with GPSLongitudeRef | From the JSON's geoData, only when the file has no position |
| Altitude | EXIF:GPSAltitude with GPSAltitudeRef | Only when the JSON altitude is not zero |
| Caption | EXIF:ImageDescription, XMP-dc:Description | The JSON description, written to both so old and new readers find it |
A date taken from a file name rather than a JSON is written the same way, without OffsetTimeDigitized. Extensions covered: .jpg, .jpeg, .jpe, .jfif, .heic, .heif, .hif, .avif, .png, .webp, .tif, .tiff.
A Pixel motion photo is a JPEG with the video appended after the image data. The rewrite keeps that trailing data intact; we tested this with a JPEG carrying an MP4 appended the same way, and the video bytes came out identical. See the Live Photos page for how the separate video parts are handled.
GIF
GIF has no EXIF block, so the same information goes into an XMP block instead:
| What | Tags written |
|---|---|
| Date | XMP-exif:DateTimeOriginal, XMP-photoshop:DateCreated, each with the offset embedded (2019:07:04 18:30:05+02:00) |
| Position | XMP-exif:GPSLatitude, XMP-exif:GPSLongitude |
| Caption | XMP-dc:Description |
An animated GIF stays animated; the frames are not touched.
MP4, MOV, M4V, 3GP and 3G2 up to 300 MB
QuickTime-family videos keep dates in several places, and different apps read different ones, so all of them are written:
| What | Tags written | Value |
|---|---|---|
| Date, container | QuickTime:CreateDate, QuickTime:ModifyDate | UTC, as the format specifies |
| Date, tracks | QuickTime:TrackCreateDate, QuickTime:TrackModifyDate, QuickTime:MediaCreateDate, QuickTime:MediaModifyDate | UTC |
| Date, Apple | Keys:CreationDate | Local time with offset, in Apple's creation-date tag, which Immich and PhotoPrism read for videos |
| Position | Keys:GPSCoordinates, UserData:GPSCoordinates | Latitude, longitude and altitude, only when the video has no position |
| Caption | Keys:Description, XMP-dc:Description | The JSON description |
A video that already has a header date equal to Google's timestamp is left unchanged under the default rule. Live Photo videos, which borrow the still's JSON, keep their own header date whenever they have one.
Videos over 300 MB
Rewriting a large video's metadata with ExifTool means rebuilding the whole file in memory, which a browser tab cannot do safely for a multi-gigabyte recording. Above 300 MB FixMyTakeout instead patches the existing creation and modification times in place, in the movie header (mvhd), each track header (tkhd) and each media header (mdhd). The file's size and every other byte stay the same. No position or caption is written to these files; the report notes Video over 300 MB: date patched in place, nothing else written when the JSON had either.
AVI, MKV, WMV, MPG, MTS and M2TS, WebM, BMP, and .MP parts
These containers either have no standard place for a capture date and position or are ones ExifTool cannot write. FixMyTakeout leaves the file bytes exactly as they came and sets only the file's modified date to the capture time, so a photo app that falls back to the file date still places them correctly. The report marks them not writable in this format in date_written. Also in this group: .asf, .mpeg, .ts, .vob, .flv, .ico, .svg, and the .MP and .MV video parts of Pixel motion photos.
RAW files
DNG, CR2, CR3, NEF, ARW, ORF, RW2, RAF, PEF, SRW and the other camera formats (CRW, NRW, SRF, SR2, X3F, ERF, KDC, DCR, MOS, 3FR, IIQ, RWL) are never rewritten. A RAW file is the camera original and nearly always carries its own capture date, so the file is left untouched and only its file date is set. If Google's JSON disagrees with the RAW's own date, the report shows the RAW's date in date_before and Google's in file_date, and you can decide.
The file date every file gets
Whatever the format, each entry in the output zip carries its capture time three ways: as the DOS timestamp in your computer's zone, in the Info-ZIP UT extra field as exact UTC, and in the NTFS extra field. Unzipping with the operating system's own tool sets each file's modified date to when it was taken, which is the date Immich, PhotoPrism and Synology Photos fall back to when a file has none inside. For the untouched formats above this file date is the whole fix.
Check a file after the fix
- Open the fixed photo in your photo app's info panel. For JPEG, HEIC and PNG the capture date and place should now show.
- If you have ExifTool installed, run
exiftool -a -G1 -time:all -gps:all -Description photo.jpgand compare the values with thedate_writtenandlocationcolumns offixmytakeout-report.csv. - For an AVI or MKV, check the file's modified date in Finder or Explorer: that is what was set.