Video Metadata Viewer

How to view video metadata online without handing over the file

Drop the file on the panel above. A video metadata viewer that works this way reads the container in your browser, so nothing is uploaded and there is no queue.

That matters more than it sounds for video. A holiday clip is a few hundred megabytes and an unreleased edit can be several gigabytes, so the usual model — send it to a server, wait, read the answer — costs you bandwidth and puts your footage on someone else’s disk. Reading it locally removes both problems.

The honest cost is memory and patience. Your browser holds the parser and seeks through the file, so a very large clip on an older laptop will take a few seconds rather than being instant. We would rather say that than promise two seconds and leave you watching a spinner.

What the video metadata viewer actually reads

More than the file properties panel shows you, and in a different shape.

• The container and every track inside it. Video, audio, subtitles and chapters, each listed separately with its language.
• Codec, profile and encoder. Not just H.264 or H.265 but the profile level and, where the muxer recorded it, the library that did the encoding.
• Frame rate and frame rate mode. Constant or variable, with the minimum and maximum where they were recorded.
• Bit depth, colour space and chroma subsampling. The fields that decide whether a grade holds up.
• Device, software and timestamps. Make, model, operating system version and up to four different dates.
• GPS coordinates, when the recording device wrote them.

One caveat we would rather state up front. A container can hold vendor-specific tags we display but do not interpret, and some cameras write proprietary blocks nobody outside the manufacturer can read. Assume a file may carry a little more than any general reader shows. The field list itself is explained in what video metadata is.

Inside an MP4 metadata reader: atoms, not EXIF

Photos carry EXIF. Video does not, and calling it EXIF sends people looking for fields that were never there. This page used to make that mistake in its own title.

An MP4 or MOV file is a tree of boxes, still widely called atoms after their QuickTime origin. The ftyp box says what the file claims to be, the moov box holds the structure of every track, and mdat holds the actual compressed picture and sound. Descriptive tags — title, device, location, copyright — live in a udta box inside moov.

This layout explains a behaviour people find odd. Recording devices do not know the final file size until you stop, so they write moov at the end. A parser then has to seek to the tail before it can say anything at all, which is why some files answer instantly and others pause first. Files prepared for web streaming move that box to the front, and that single difference is what makes a video start playing before it has finished downloading.

How to read MKV tags and the tracks most tools ignore

Matroska works differently, and it is where the interesting files live.

Instead of nested boxes it uses EBML elements, with a Tags section for descriptive data and a Tracks section describing every stream. The practical consequence is that an MKV routinely carries several audio languages and a dozen subtitle tracks, while your operating system property panel reports one of each.

Our tab strip above lists every track with its own entry, labelled by language where the muxer recorded it. This is the fix for a real defect: the previous version keyed tabs by track type, so a file with two audio streams produced duplicate keys and only ever displayed the first. The page advertised multi-track support while quietly failing at it.

If all you need is the headline technical answer rather than a full field dump, the codec and bitrate checker gives you five fields and stops.

Running a video file information checker before you edit

Editors have a specific reason to look, and it is not curiosity.

Screen recorders, phones and OBS often produce variable frame rate footage, where the rate moves around to save space. Premiere and Resolve both handle that badly, and the symptom is audio that starts in sync and drifts apart over a long clip. Ten minutes in, dialogue no longer matches lips.

The fix is to transcode to a constant rate before you start cutting, not after you notice. We flag the mode in the summary above, and there is a dedicated constant or variable frame rate test that answers only that question. Worth checking the codec too — an H.264 or H.265 mix-up explains a surprising share of timeline stutter on older machines.

Why our parser now comes from our own server

This section exists because the previous version of this page was not telling the truth, and we would rather say so than quietly fix it.

The page claimed strictly offline operation and zero backend architecture. Your video did stay on your machine. But the parser and its WebAssembly binary were fetched from a public package CDN every time the page loaded — no version pin, no integrity check. Whatever that host served ran in the page with full access to the file you had just opened.

It also meant the tool simply failed on any network that blocks that host, and failed completely with no connection at all, while the title said offline. Both problems are gone: the library was already a dependency, and it is now bundled and served from the same origin as the page. That is the only version of this claim worth making.

What a container cannot tell you

Metadata describes what a file says about itself. It is not evidence, and video tempts people to treat it as such more than photos do.

Every field here can be rewritten with free tools. Dates move, device names get invented, coordinates get copied from an unrelated clip. Meanwhile a video that travelled through a messaging app arrives with almost nothing left, which proves only that it travelled.

So a rich, internally consistent set of fields is weak supporting evidence, and an empty one proves nothing at all. We go through what survives scrutiny in whether video metadata can be faked, and the timestamp question specifically in working out when a video was recorded.

Look inside before you send it out

A video metadata viewer earns its place in the minute before an upload, not the week after. Open the file, read what it carries, and decide on purpose.

If it holds coordinates or a device name you would rather not publish, our video metadata remover rebuilds the container without them and copies the streams across untouched, so nothing is re-encoded. Phone footage is the usual culprit, and whether videos store GPS explains which devices write it. Need the file smaller for an upload limit as well? Compress the video afterwards rather than before. And if it is a photograph rather than a clip, our photo metadata viewer does the equivalent job for JPEG, PNG and HEIC.