What Photo Exports Actually Give You

Four services, four different answers

Three patterns fall out. Two services put your metadata in a file beside the photo, one re-encodes to a quality you choose, and the last row is not an export.

Google Takeout: the file beside the file

Takeout hands back your media with a JSON file beside each item. That JSON holds what you did inside Google Photos: the description you typed, the location you set, and timestamps under names like photoTakenTime and creationTime, in seconds since 1970.

The name of that file changed, and that broke a great many community scripts. It used to be IMG_1234.jpg.json. Newer exports attach a .supplemental-metadata suffix, and because Takeout clips long filenames the suffix frequently arrives chopped. Ente’s upload code notes that exports are “attaching a ‘.supplemental-metadata’ suffix to the file name of the metadataJSON file … and then clipping the file name if it’s too long,” producing names such as very_long_file_name.jpg.supple.json. The immich-go importer matches any leading fragment of that word, and allows for a name truncated at 46 characters.

Quality was settled long before you clicked Export. Google documents two backup settings. Original quality stores photos and videos “in the same resolution that you took them with no change to their quality.” Storage saver, “previously named High quality,” stores them “at a slightly reduced quality”: above 16 MP a photo “will be resized to 16 MP,” video above 1080p is “resized to high-definition 1080p,” and uploads “may be compressed into a different image format, like a .jpg.” Choose the smaller option in 2017 and no export in 2026 recovers what your camera made.

Google also offers a direct transfer to another service, copying “the photos, videos, albums, and descriptions saved in your Google Account,” though unsupported file types cannot transfer. Our walkthrough on Google Takeout photo dates covers reassembling the pieces.

Apple Photos: XMP, not JSON

This is the part most often got wrong, so the words first. Apple’s current app is Photos, usually written Apple Photos. iPhoto was its predecessor; “iPhotos” is not a product name and never was. iCloud Photos is the sync service that, in Apple’s words, means “your photos and videos are always with you, no matter which device you’re using.” There is no iCloud export format; the real export happens in the Photos app.

Apple’s Photos User Guide describes two export routes that do genuinely different things. File → Export → Export [number] Photos re-encodes: you pick a Photo Kind of JPEG, HEIC, TIFF or PNG, plus a quality, a size and a color profile. Export Unmodified Original does not re-encode; in Apple’s wording it exports photos “in the original file format in which they were imported into your Photos library.”

And in that second flow sits the sentence that settles the sidecar question. To export IPTC information — “assigned IPTC metadata and keywords” — “as a sidecar XMP file, select the Export IPTC as XMP checkbox.”

Which raises a question Apple does not answer. Photos lets you correct a date, and its “Revert to Original Location” command “removes the location information you assigned” — so assigned values and originals are both kept in the library, separately from the file. Apple’s export pages do not say whether a corrected date is written into an unmodified original on the way out, and we found no primary source either way. Check a few files first.

Meta and Flickr: the quality dial

Facebook and Instagram share one export mechanism, in Accounts Center. Meta’s Instagram Help Center describes the request: you “choose specific info to export and select a date range, format, notification email address and media quality.” What Meta does not do, as of 31 July 2026, is say what any level means in pixels, or promise the highest returns the file you uploaded.

Flickr is more forthcoming, and more restrictive. Its Help Center states “your downloaded photos will only contain the EXIF data that existed when they were uploaded to the Flickr account,” and that “any information added to the photos after they were uploaded, such as a Title, Description, or Tags, will be in a separate JSON file.” Same architecture as Google, different vocabulary. It also documents that free accounts “cannot offer downloads of original or large-size photos (larger than 1024px),” that videos “are excluded from all bulk downloads, regardless of account type,” and that links to a prepared archive are “time sensitive and will expire.”

Flickr gives the cleanest illustration of the sidecar problem. It lets you edit a photo’s Date Taken in the browser and orders your library by it — but per its own EXIF FAQ, anything added after upload goes into the JSON. Correct a date on Flickr, download the photo, and the file carries the old one.

One more, the trap almost nobody knows about. Apple’s Shared Albums page states plainly: “Shared Albums upload a copy of your data. Downloaded content may not contain the same information as the original.” And: “When shared, photos are reduced to 2048 pixels on the long edge, except panoramic photos, which can be up to 5400 pixels wide.” Videos are “delivered at up to 720p resolution.” Saving a relative’s wedding photos from a Shared Album feels like getting the photos. It is not.

A separate file gets separated

Underneath all of this is one design decision. Metadata can live inside the image file or in a companion file beside it, and what lives beside the photo can be parted from it. In a library move, it usually is.

Sidecars are not a mistake, and the companies using them explain why. Adobe’s Lightroom Classic documentation is blunt: “In the case of camera raw files that have a proprietary file format, XMP isn’t written into the original files. XMP metadata is stored in a separate sidecar file to avoid file corruption.” The IPTC, which publishes the metadata standard nearly everyone uses, agrees: sidecars exist “for camera Raw files as some of these file formats do not support embedded metadata.”

The other half of that sentence is the crux: “For all other file formats supported by Lightroom Classic (JPEG, TIFF, PSD, and DNG), XMP metadata is written into the files.” When embedding is possible, the industry embeds. Which makes the export situation odd, because your Takeout JSON sits beside an ordinary JPEG — a format that has held metadata internally for decades. The sidecar exists not because the file cannot carry the data, but because the service kept it in a database and is handing you a copy.

The failure is quiet, which is what makes it expensive. Nothing errors and the photographs import perfectly. It is weeks later, when a decade of family life sits under one date, that anyone notices.

Four things widely repeated that are not true

1. “Apple exports include JSON sidecars” — and “Apple exports have no sidecars at all.” One page disproves both. Apple’s Photos User Guide describes exactly one sidecar, calls it “a sidecar XMP file,” and puts the checkbox that writes it in the Export Unmodified Original dialog.
2. “I exported from iCloud.” iCloud Photos is a sync service, described in Apple’s guide as keeping your photos with you across devices. There is no iCloud export format and no iCloud sidecar.
3. “Google Takeout strips the EXIF out of your JPEGs.” We found no Google documentation saying this, and will not repeat it as though someone had. What Google documents is a compression choice made at upload, years earlier.
4. “Just rename the .json files and any tool will pick them up.” Not reliably. The clipping means the suffix can survive as any fragment of the word, or vanish and take part of the filename with it.

Does the law get you your originals?

“Download your data” buttons are often called a legal right, so it is reasonable to hope the law guarantees a full-quality copy. It does not. Article 20 of the GDPR grants the right “to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format,” and, where technically feasible, to have it “transmitted directly from one controller to another.”

Read it for what it does not contain. No mention of resolution, image quality, original files or completeness. “Machine-readable” is about format, not fidelity: a 1024-pixel JPEG is as machine-readable as a raw file. That is not a criticism of a regulation never written about photographs; it is a caution against assuming a right you do not have.

Nor, as far as we could establish, does any of these services state that its export is complete. Google explains its format choices as what it believes is “most useful and portable” — a judgment, not a guarantee. If completeness matters, the only evidence is your own count of what came back.

What to do before you move a library

None of this needs special software. Most of it is restraint.

• Check what you asked for at upload, not at export. No export returns quality the service never held.
• Do not reorganize before importing. Leave the folder structure alone; keep every JSON or XMP file with its image.
• Never delete sidecars to save space. They are tiny, and the only copy of anything you added inside the service.
• Watch the clock. Flickr states that its data links are time sensitive and expire.

If the check goes badly, the useful distinction is between a date that still exists somewhere in the evidence and one that never existed at all. The two need different treatment, which is what our guide on fixing wrong photo dates is organized around.