What metadata can videos contain?
Video carries the same kind of identifying information as photos, in several places at once, and removing it naively will break the file.
8 min read · Updated
Where video metadata lives
MP4 and MOV are box-structured files. Metadata appears in at least three distinct places:
- A udta box holding classic QuickTime atoms — ©mak (make), ©mod (model), ©swr (software) and ©xyz, which is an ISO 6709 location string.
- A meta box containing a keys table paired with an ilst value list. This is the Apple style, and it is where an iPhone records make, model, software and GPS.
- The mvhd, tkhd and mdhd headers, each storing a creation and a modification time counted in seconds from 1 January 1904.
WebM is different
WebM and Matroska store a Title, a MuxingApp and WritingApp naming the software that produced the file, a DateUTC, a unique SegmentUID, and optional Tags.
The SegmentUID is worth noting: it is a unique identifier per file, which makes two copies of the same video linkable even if nothing else identifies them.
Why naive removal breaks playback
This is the part that catches tools out. MP4 sample tables — stco and co64 — store absolute byte offsets into the mdat box that holds every encoded frame.
Delete a metadata box that sits before mdat and every one of those offsets is now wrong by exactly the number of bytes you removed. The file still looks valid, and some players may even open it, but seeking misbehaves and playback fails.
Doing it correctly means modelling each change as a byte-range edit, deriving an old-offset-to-new-offset map, and rewriting the offset tables to match. That is what happens here, and the cleaned output is decoded end to end by an independent decoder in the test suite to prove it.
Why WebM files stay the same size
WebM records byte positions in its SeekHead and Cues elements, so deleting metadata would invalidate the seek index in the same way.
Instead, each unwanted element is overwritten with an EBML Void element of exactly the same size — the mechanism the format defines for this situation. The data is genuinely gone; the space it occupied is now padding. That is why a cleaned WebM has an unchanged file size, and it is deliberate rather than a failure.
No transcoding, ever
Re-encoding a video to remove metadata would take minutes, degrade the picture, and be entirely unnecessary — the metadata is not inside the video stream.
Cleaning here rewrites only the container and leaves the encoded video and audio untouched. A multi-gigabyte recording is processed in seconds, and track rotation is deliberately preserved so a video shot on a phone still plays the right way up.
Questions
Does cleaning a video re-encode it?
No. Only the container is rewritten; the encoded video and audio streams are copied verbatim. Cleaning the same file repeatedly produces identical media every time.
What about the creation date my operating system shows?
That comes from the filesystem, not the file, and is set when the download is written to disk. The timestamps inside the container — the ones that travel with the file when you send it — are what cleaning zeroes.
Is drone footage different?
It deserves particular attention: drone video almost always carries GPS, and GoPro and DJI files add vendor-specific boxes alongside the standard ones. Those are detected and removed as metadata.