Your file explorer shows a size, a length and a date. The file itself knows the codec of every track, which application wrote it, the model of the phone that shot it and, often enough, where you were standing.
Video metadata is that structure. It sits alongside the picture and sound rather than inside them, which is why it can be read in a fraction of a second and removed without touching a single frame.
What is video metadata, in one paragraph
A video file is a container holding several things: one or more streams of compressed picture and sound, a timing map that says when each piece should appear, and a set of descriptive tags. The tags are the metadata, and they are the part nobody sees.
You can read all of it for a file of your own in our video metadata viewer, which parses the container inside your browser without uploading anything.
Why video has no EXIF, and what it uses instead
Photos carry EXIF. Video does not, and calling it EXIF sends people looking for fields that were never defined.
An MP4 or MOV file is a tree of boxes, still widely called atoms after the QuickTime format they came from. Each box has a four-character name and a length, and boxes nest inside each other. Three matter most:
- ftyp sits first and declares what the file claims to be, using brand codes like isom or qt. It is how a player decides which rules apply before reading anything else.
- moov holds the structure: every track, its codec, its timing, its duration. Without it a player has data and no idea what to do with it.
- mdat holds the actual compressed frames and audio samples, and it is nearly the whole file by size.
Descriptive tags live in a udta box nested inside moov. Title, copyright, the software that wrote the file, and on phones the location string all sit there.
The moov and udta atoms explain a behaviour you have noticed
Where moov sits decides how a file behaves, and it explains something most people have run into without knowing why.
A camera cannot know the final size of a recording until you stop, so it writes moov at the end. That is efficient and it means any tool wanting the structure has to seek to the tail first. On a four-gigabyte file over a slow drive, that is a noticeable pause before anything appears.
Files prepared for streaming move that box to the front, an operation usually called faststart. It changes nothing about the picture and it is the entire reason a web video starts playing before it has finished downloading. If you have ever wondered why one MP4 streams and another downloads first, this is why.
Matroska tags explained, and why MKV files hide more
Matroska takes a different approach and it is the format where the surprises live.
Instead of nested boxes it uses EBML, a binary structure of typed elements. A SegmentInfo element near the front carries the muxing application, the writing application and a creation date. A Tracks element describes every stream. A Tags element holds arbitrary key and value pairs, and it can appear at the end of the file rather than the start.
The practical consequence is track count. An MKV routinely carries several audio languages and a dozen subtitle tracks, each with its own language code and its own name. Your operating system property panel will show one of each, which is how people end up convinced a file has no subtitles when it has eleven.
One quirk worth knowing: Matroska makes the muxing and writing application elements mandatory. A valid MKV always names whatever built it, which is why a stripped file still carries one line it cannot legally drop.
QuickTime creation date fields, and the timestamp that looks wrong
Video files carry several dates, and reading them as one number causes most of the confusion around them.
The encoded date is written by the muxer when the file is created, and the MP4 specification says it is UTC. The tagged date moves whenever software rewrites the metadata. On Apple devices there is also a com.apple.quicktime.creationdate field that carries a real timezone offset.
So a clip filmed at ten in the morning in London during summer shows an encoded date of 09:00 and an Apple creation date of 10:00+0100. Both are correct. Neither is wrong. People discovering this for the first time reliably conclude their file has been tampered with, which is why we list the dates separately rather than merging them into a single reassuring line. The whole question gets its own treatment in working out when a video was recorded.
Which video fields identify you, ranked
Not all of it is sensitive, and treating the whole block as one undifferentiated risk leads people to either panic or shrug.
Genuinely identifying. GPS coordinates first, by a wide margin — an iPhone writes a location string accurate enough to name a building. Device make and model second, which narrows you to a hardware type and, combined with anything else, to a person. Any copyright or author field carrying a real name third.
Contextually revealing. Timestamps establish when you were somewhere. Software fields say which tools you own and roughly what you paid for them. Track languages hint at who the file was prepared for.
Harmless. Codec, bitrate, resolution, colour space, sample rate. Nobody has ever been located from a chroma subsampling value.
These sit together in the same container, so removing the risky ones means rewriting the box. Our video metadata remover does that without re-encoding, and whether videos store GPS covers which devices write coordinates in the first place.
How metadata gets lost on the way to you
Most video you receive arrives with almost nothing, and that is normal rather than suspicious.
Messaging apps and social platforms re-encode on upload, which produces a new container written from scratch. The tags do not survive that, so the copy in your chat has none while the original on the sender's phone still has all of them.
Editors are less predictable. Some preserve everything they understand and drop what they do not. Most write their own name into the file, which is why a clip can announce which software touched it while revealing nothing about the camera.
This is also why absence proves nothing. A file with no metadata may have been cleaned deliberately, or may simply have travelled through one app.
What to do with any of this
Understanding what is video metadata changes two habits, and both are small.
Before an upload to anywhere public, look at what the file carries. It takes seconds and the answer is usually reassuring. Before an edit, check the technical fields instead — the codec and bitrate checker covers what will play and what will not, and a variable frame rate check catches the timing problem that ruins long timelines.
And treat the fields as claims rather than facts. Every one of them can be rewritten, which is the subject of whether video metadata can be faked. If you want the codec question specifically, telling H.264 from H.265 is the practical version.