The 11 MP4 metadata fields Instagram strips on upload — and the 4 it keeps

What a fresh iPhone recording looks like — before upload

Record a 10-second clip on iPhone 15 Pro. Pull it off the phone without uploading anywhere. Run `ffprobe -show_format -show_streams` on the .mov file. You'll see around fifteen to twenty metadata fields: `com.apple.quicktime.make` (Apple), `com.apple.quicktime.model` (iPhone 15 Pro), `com.apple.quicktime.software` (iOS 18.2), `com.apple.quicktime.creationdate` (with timezone), `com.apple.quicktime.location.ISO6709` (GPS lat/long/altitude), `com.apple.quicktime.content.identifier` (a per-recording UUID), and a cluster of camera-setting tags that Apple encodes for photos integration. Creation timestamp lives at both the container level and the video stream level. There's usually a `timecode` track. Sometimes a `subtitle` track for burned-in captions.

Upload that same file to Instagram as a Reel. Wait for the post to go live. Download the Reel back through any tool — ours, yt-dlp, whatever. Run ffprobe on the result. You'll see four metadata fields. Four.

What survives — the 4 fields Instagram keeps

Pulled a raw DASH segment straight from Instagram's CDN on 2026-04-23, without going through our merge step. The file's format-level tags:

`major_brand=mp41` — the standard MP4 container brand, not Apple's `qt` extension or `iso4`. Everything that survives the pipeline ends up as baseline MP4.

`minor_version=0` — version signal for the brand. Unchanging across every Reel we've examined.

`compatible_brands=iso8isommp41dashavc1cmfc` — the list of container profiles the file conforms to. `iso8` is ISO BMFF 2019, `isom` is generic ISO base media, `mp41` is MP4 v1, `dashavc1` is DASH Industry Forum's H.264 profile, `cmfc` is Common Media Application Format — everything DASH streaming needs.

`creation_time=2025-09-05T18:13:42.000000Z` — this is the timestamp Instagram wrote when their transcoding pipeline re-encoded the file, not when the creator originally recorded it. Every Reel we've checked has its `creation_time` aligned to the upload-transcode moment, not the camera-capture moment.

The video stream carries three more fields: `creation_time` (same as the container), `handler_name=VideoHandler` (standard QuickTime atom label), `encoder=AVC Coding` (generic H.264 tag). Neither the creator's device nor any settings leak through.

That's it. The entire surviving metadata universe.

What gets stripped — the 11 fields that don't survive

Here's the list, in rough order of privacy / forensic value:

**GPS location** — `com.apple.quicktime.location.ISO6709` encodes the exact lat/long/altitude where the clip was recorded. Strip this and you lose the ability to tell where a viral Reel was actually shot from the file alone. Meta strips this across the board. Whether the creator disclosed the location separately (via a geotag, a caption, or the creator's own watermark) is a different question — but the EXIF-ish metadata coordinate is gone from the file.

**Device model** — `com.apple.quicktime.model` told you it was shot on iPhone 15 Pro specifically. Useful for forensic work (does the low-light look match what that sensor produces?) and provenance verification. Gone.

**Device manufacturer** — `com.apple.quicktime.make=Apple`. Even the brand is removed.

**OS / software version** — `com.apple.quicktime.software=18.2`. Would have told you what iOS build processed the original recording. Gone.

**Original capture timestamp with timezone** — `com.apple.quicktime.creationdate` on an iPhone is a timezone-aware ISO 8601 string including the offset at the moment of capture. Meta's pipeline replaces this with a UTC `creation_time` at transcode moment, stripping both the original capture timestamp and the timezone offset.

**Content identifier** — `com.apple.quicktime.content.identifier` is a UUID iOS generates per recording session. It links Live Photos' still + video pair, and some apps use it for deduplication. Strip this and you can't reliably link "this Reel was edited from the same raw clip as that other Reel" from metadata alone.

**Camera settings atoms** — Apple writes a cluster of `com.apple.quicktime.camera.*` and `com.apple.quicktime.meta.ios.camera.*` atoms covering ISO, exposure, focal length in 35mm equivalent, white balance, and HDR mode. All removed. Professional post-production work that relied on reading camera settings off the source file is stuck without them.

**Author / artist / title / comment** — the generic iTunes-style metadata atoms. If the creator wrote a comment in their editing software before uploading, Instagram discards it.

**Timecode track** — professional workflows often carry a separate SMPTE timecode track for frame-accurate editing. Stripped.

**Subtitle / caption track** — if the original file had a separate text track (not burned-in to the video pixels), Instagram's re-encode doesn't preserve it. Burned-in captions survive because they're part of the video frames; separate tracks don't.

**Chapters** — ffprobe's `-show_chapters` returns empty on every Reel. Long-form content that originally had chapter markers loses them on upload.

Why Meta strips these — the three honest reasons

Privacy is the front-of-house reason, and it's real. GPS coordinates in a shared video file expose recording location to anyone who downloads the clip. Most users assume their Reel doesn't carry that data; most apps that let you share video preserve EXIF by default; Meta stripping it is the safer-than-not-default that matches user expectations.

Payload size is the infrastructure reason. At Meta's scale, the metadata overhead for retained EXIF adds kilobytes to every asset. Scale that across billions of Reels and tens of thousands of edge caches and the storage plus egress cost becomes real money. Stripping is a cost-control lever, not just a privacy lever.

Standardization is the third reason, and the one that explains why the surviving metadata set is so consistent. Meta's transcoding pipeline rewrites the MP4 container to a known-good baseline profile that every decoder on every platform handles identically. Apple-proprietary atoms, iOS-specific tags, third-party editing-software metadata — all get stripped as part of that normalization. The resulting file is smaller, faster to validate, and decodes the same on every device. Consistency wins over fidelity-to-source.

What this means if you're using a downloader for provenance

Journalists, researchers, and investigators sometimes use Instagram downloaders to archive posts. The assumption is that the download is "the file as posted". That's true pixel-wise. It's not true metadata-wise.

If you're trying to establish when a clip was originally recorded — the downloaded MP4 tells you when Meta transcoded it, not when the creator's camera captured it. Those times can be hours, days, weeks, or months apart. The upload transcoding runs shortly after the creator tapped Post, which tells you approximately when the Reel went public but nothing about when the raw footage was shot.

If you're trying to establish where a clip was recorded — the downloaded MP4 has no GPS data. If the creator geotagged the post, that tag exists separately (in the post metadata, not the video file itself, and we do surface it via `/api/parse` under `metadata.author` and related fields). But the raw location coordinates that would survive in the original iPhone recording aren't in the downloaded file.

If you're trying to establish what device recorded the clip — again, stripped. A Reel from a verified news outlet's account could have been shot on an iPhone, a RED Komodo, or a BlackMagic Pocket — the downloaded file won't tell you which.

The practical workaround for provenance work: find the creator's original file. For public-interest footage, creators often share raw sources on request. For archival work where the original isn't available, acknowledge the limit — the downloaded file is canonical as-posted but not as-recorded.

Is there anything recoverable?

A few things, but not via the file itself.

The `/api/parse` endpoint on our side returns an Instagram-side metadata block alongside the video URLs. The block contains `author` (display name), `caption` (the post text), `timestamp` (the ISO 8601 post time Instagram records — different from the video creation_time inside the MP4), and `thumbnail` (the cover URL). For the Reel we tested today, that timestamp was `2025-04-01T13:05:19.000Z`, about five months before the transcode's `creation_time=2025-09-05`. Worth noting: even Instagram's post-level timestamp is the post time, not the original recording time. The gap between original capture and final post isn't something Instagram tracks publicly.

For creators dealing with copyright or DMCA claims, the upload log on your own account tells you exactly when you posted (visible in your activity log). That's more reliable than trying to extract a timestamp from a downloaded file you or someone else pulled later.

For forensic use cases where GPS / device provenance matters and you can't get the original file — you're out of options on the file side. External evidence (social-media context, reporter interviews, scene analysis) is how investigators work around it.

How to check for yourself

Install ffmpeg. Pick any Reel you've downloaded. Run: `ffprobe -v error -print_format json -show_format -show_streams <file.mp4>` and pipe through `jq` or Python's `json.tool` for readability.

Look at `format.tags` and each stream's `tags` object. Count the entries. Compare to what an iPhone or Android recording would have (you can generate a baseline by recording a fresh 5-second clip yourself and ffprobe'ing the unprocessed file before any upload).

Pay attention to `creation_time` specifically — if the date looks "too recent" for a Reel the creator posted months ago, that's the transcode stamp, not the record stamp.

For the atoms that QuickTime-specific tooling reads, try `exiftool <file.mp4>` which surfaces more fields than ffprobe by default. Every Reel we've run through exiftool comes back with almost nothing QuickTime-specific because Meta strips those atoms entirely. MDN has a primer on the MP4 container format at https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Containers#mpeg-4_mp4 if you want to go deeper on the box hierarchy.

The summary table

**Fields Meta keeps (4):** major_brand, minor_version, compatible_brands, creation_time (transcode time, not record time).

**Fields Meta strips (11+):** com.apple.quicktime.make, com.apple.quicktime.model, com.apple.quicktime.software, com.apple.quicktime.creationdate (timezone-aware), com.apple.quicktime.location.ISO6709 (GPS), com.apple.quicktime.content.identifier, camera settings atoms (ISO/exposure/focal), artist/title/comment tags, timecode track, subtitle / caption track, chapters.

**What Meta replaces:** the file-level `creation_time` is rewritten to the moment of transcoding. The container itself is remuxed to a DASH-compatible baseline MP4 profile.

**What this means in practice:** downloaded Reels are pixel-canonical but not metadata-canonical. For provenance, archival, or forensic work, treat the download as "the file as published", and look to external sources for everything about "the file as recorded".