Video Metadata Viewer

What the report actually tells you

Most of the time people arrive here because something rejected their file, and the rejection did not say why. Upload limits are almost always about four things: the container, the video codec, the resolution or frame rate, and the audio codec. All four are in the first two blocks of the report, so the comparison against whatever limits the service publishes takes a few seconds.

The per-stream detail matters more than it looks. A file can be a perfectly valid MP4 and still be rejected because the video is HEVC rather than H.264, or because the audio is AC-3 rather than AAC, or because the pixel format is yuv444p where the target expects yuv420p. The container name alone never tells you that; the stream table does.

Subtitle and data streams are listed too. A video that plays fine locally but loses its captions after conversion usually had a subtitle stream the conversion dropped, and seeing it listed here is the fastest way to confirm that is what happened.

Why it runs in the browser

The inspection uses ffmpeg compiled to WebAssembly, running inside the page. That is why it reads containers the browser itself cannot play: a browser refuses an MKV or a WMV outright, while ffmpeg reads the stream table of both. It is the same reason the first inspection takes a moment, since the decoder is about 32 MB and has to be fetched once. Your browser caches it and later files are immediate.

Running locally is not only a privacy line. The files worth inspecting are often the ones that cannot be uploaded anywhere: unreleased footage, a client cut, a recording of a private call. A tool that required an upload would be useless for exactly the files people most need to check.