Everyone knows photos carry EXIF data by now — the John McAfee saga of 2012, where a single Vice photo's GPS coordinates gave away his hideout in Guatemala, made sure of that. Videos somehow escaped the same reputation. Which is odd, because your phone stamps every video with much the same information: where you were standing, precisely when you pressed record, and exactly which device you own. It just files that information somewhere fewer people know to look.
That somewhere is the MP4 container. Understanding roughly how it's organized — no hex editor required, I promise — explains both what's recorded about you and why removing it properly is trickier than it sounds. It also explains why most of the advice you'll find ("just re-encode it!") solves the problem in about the worst available way.
Boxes all the way down
An MP4 file (and its close sibling, Apple's MOV — both descend from the QuickTime format, standardized as the ISO Base Media File Format) is a stack of nested containers called boxes, or "atoms" in the older QuickTime vocabulary. Each box starts with a 4-byte length and a 4-character type code, then its payload — which is often more boxes. It's Russian dolls, with four-letter names.
A typical phone video has a ftyp box declaring the file type, a huge mdat box holding the actual compressed audio and video, and a moov box — the index that describes everything: how many tracks, what codecs, where each frame sits inside mdat. The metadata that concerns your privacy lives almost entirely inside moov and its descendants. The pixels don't know where you were. The bookkeeping does.
The atoms that talk about you
Three categories matter: timestamps, location, and device identity.
Timestamps are structural — they're baked into required header boxes, not optional extras. The movie header (mvhd), each track header (tkhd) and each media header (mdhd) all carry a creation_time and modification_time, stored as seconds since midnight on January 1, 1904 (a QuickTime quirk that has outlived several generations of engineers). A single video with one video track and one audio track therefore contains at least six timestamps saying when it was made. Renaming the file or touching its filesystem dates changes none of them.
Location usually sits in the user data box, udta, as an atom named ©xyz — that's a copyright symbol plus "xyz", one of QuickTime's four-character codes. Its payload is an ISO 6709 coordinate string like +37.7749-122.4194+018.337/: latitude, longitude, sometimes altitude, to more decimal places than your car's navigation uses. Android camera apps have written this atom for over a decade when location tagging is on. iPhones store location under Apple's metadata keys as com.apple.quicktime.location.ISO6709, same coordinate format, slightly different address inside the file. Either way: anyone who obtains the file can read your position to within a few meters.
Device identity rounds out the picture. Apple devices write com.apple.quicktime.make, com.apple.quicktime.model and com.apple.quicktime.software — literally "Apple", "iPhone 16 Pro", and the iOS version. Android vendors have their own equivalents in udta. Harmless-sounding, but combined with timestamps and location it turns a random video file into "shot on this exact phone model, at these coordinates, at 11:42 p.m. on this date."
| Box / atom | Where it lives | What it stores |
|---|---|---|
mvhd | moov | Movie-wide creation and modification times, duration, timescale |
tkhd | moov/trak | Per-track creation and modification times (one pair per track) |
mdhd | moov/trak/mdia | Media creation and modification times, language code |
©xyz | moov/udta | GPS coordinates as an ISO 6709 string (common on Android) |
Apple keys/ilst items | moov/meta | location.ISO6709, make, model, software, creationdate (iPhone) |
udta (misc.) | moov | Vendor extras: encoder names, app tags, occasionally orientation hints |
Want to see your own file's version of this? Drag one into a metadata inspector — our metadata viewer handles video containers as well as images, locally in your browser — or run ffprobe if you're comfortable with a terminal. The first time you see your home coordinates printed next to a video you almost posted publicly is usually the last time you skip checking.
Who actually sees this stuff
Fair question, because the big social platforms do strip most container metadata on upload — as of mid-2026, videos posted to Instagram, TikTok or X come back out without GPS atoms, same as photos. But the platform-strips-it defense has holes you could drive a truck through:
- Anything sent "as a file" — Telegram documents, email attachments, WeTransfer links, Google Drive shares — arrives byte-for-byte intact, metadata and all.
- Marketplace listings, dating apps, forums and smaller sites vary wildly; some re-encode, some serve your original file untouched.
- Files you hand to a buyer, a landlord, a client or a journalist never pass through any stripping layer at all.
- Platform behavior is policy, not physics — it changes without notice, and you find out after the fact.
The pattern is the same one we've written about for images: the risk isn't the big public post, it's the direct handoff. If you already scrub location from photos with a GPS metadata remover before selling furniture online, your videos deserve teh same reflex — they carry more precise data, not less.
Play out one ordinary scenario. You're selling a couch, and the marketplace buyer asks for a quick video to check the fabric. You shoot thirty seconds in your living room and send it over — as a file, because that's what the chat app does with videos over a certain size. If location tagging was on (it's the default on most phones once you've granted the camera permission), that stranger now holds your street-level coordinates, the fact that you own a flagship phone worth resale money, and a timestamp pattern hinting at when you're home. Probably nothing comes of it. But "probably nothing" is doing a lot of work in that sentence, and the entire exposure was avoidable with one cleanup step.
Why "just re-encode it" is bad advice
The most common fix you'll see recommended is running the video through a converter or an editor and exporting fresh. It works, in the sense that the output usually lacks the original atoms. But look at what you paid: the video gets decompressed and recompressed, and modern codecs are lossy, so every generation costs visible quality — blocking in dark areas, smeared fine detail, shimmering text. A phone clip that took 200 MB to store at high quality comes out either noticeably worse or noticeably bigger, and either way the process takes minutes of CPU time for what is, at heart, a bookkeeping edit.
It can also backfire. Exports aren't blank slates: encoders happily stamp their own identity into the new file, and some editors carry source timestamps forward. You've paid a quality tax and traded one set of fingerprints for another.
Re-encoding to remove metadata is like retyping an entire letter to change the return address on the envelope. The address was never in the letter.
Surgical removal: fixing the envelope, not the letter
Because metadata lives in specific, well-defined boxes, the right fix is structural: open the container, deal with the offending boxes, leave the compressed audio and video untouched. Not one pixel is recompressed; the operation takes seconds even on multi-gigabyte files.
There are two ways to do the surgery. One is rebuilding the file without the metadata boxes — effective, but it means rewriting the whole file and recalculating internal offsets, since moov stores byte positions into mdat. The other, which our video metadata remover uses, is to overwrite the boxes in place: GPS and device atoms are neutralized where they sit (a box can be renamed to the standard free type, which every player skips), and the structural timestamps in mvhd, tkhd and mdhd are zeroed out in place rather than deleted, since players expect those headers to exist. Because nothing moves, no offsets break, and the file stays exactly the same size — just with the sensitive bytes gone. Everything runs in your browser; a video of your kids or your apartment never gets uploaded to anyone's server in the name of privacy.
One more wrinkle worth knowing: editing apps don't reliably help you here. Trim a video in your phone's gallery, or pass it through a mobile editor, and the exported result frequently inherits the original's creation date and sometimes its location atom too — the editor copies the source's metadata forward because that's what users expect for their own library. So "I edited it, it must be clean" is not a safe assumption. The only version of the file you should treat as sanitized is one you've actually sanitized.
Afterward, verify. Run the cleaned file back through an inspector and confirm the location atom is gone and the creation times read as empty or epoch values. Trust, but grep.
A reasonable default
You don't need to sanitize every clip that stays in your camera roll — that metadata is genuinely useful for your own library, and it's how your gallery app builds those maps and memories features. The line to draw is simpler: the moment a video is going to someone you don't fully trust with your address, your schedule and your phone model, strip it first. That's most videos that leave your phone, honestly. Thirty seconds of cleanup versus permanent coordinates in a stranger's downloads folder — the math isn't close.