Video Inspector — read what's actually inside your video file

A video file is not one thing. It is a container holding one or more video streams, one or more audio streams, timing information, and metadata — and any of those layers can be the reason a file won't play, won't import, or won't upload. The Video Inspector on this page reads those layers locally in your browser and tells you, in plain English, what you have and what it means. No upload, no account, no waiting. Drop the file and read the result in seconds.

What the inspector actually reads

When you drop a file, the tool examines the header bytes — typically the first few kilobytes — rather than scanning the whole file. That is why a 60 GB recording inspects as quickly as a 60 MB clip. From those header bytes it extracts:

Container format. The wrapper format: MP4, MOV, MKV, WebM, FLV, MPEG-TS, and others. The container determines which players and editors can open the file, how seeking works, and how gracefully the file survives an interrupted write. The container is identified by file signature, not by file extension, so a file renamed from .mkv to .mp4 will still be identified correctly.

Video stream basics. Width, height, and — where the browser can determine it — codec and frame rate. Browsers expose resolution reliably through the HTML5 video element; codec details sometimes require a deeper probe with ffprobe, which the inspector will suggest when relevant.

Duration. Whether the file reports a playable duration. This single field tells you a great deal: a file with a valid duration has a readable index; a file with no duration usually has a damaged or missing index even if the media data is intact.

File size. Reported in megabytes, sanity-checked against what you'd expect for the duration and bitrate. A 90-minute recording showing as 2 MB almost certainly did not record properly.

Why browser-based inspection matters

Most "video checker" tools online ask you to upload the file. For anything private — client work, personal recordings, unreleased content — that is a meaningful privacy trade. This inspector runs entirely in your browser tab using the File API: the bytes are read locally, analyzed locally, and never leave your machine. You can verify this yourself by opening your browser's network tab or disconnecting from the internet entirely before dropping a file. The result will be identical.

The trade-off is depth. A browser probe reads what the HTML5 media element exposes, which covers container, dimensions, and duration. It does not perform a frame-level integrity scan. For that level of detail, the inspector points you to ffprobe, the command-line companion to FFmpeg:

`` ffprobe -hide_banner -show_streams -show_format your_file.mp4 ``

That command prints every stream, its codec, bitrate, frame count, and timing — the full forensic picture. Paste anything confusing from its output into the Repair Command Generator on this site and it will translate the jargon into a next step.

Reading the result: what each outcome means

Container identified, duration present, size plausible. The file is structurally healthy. If it still won't play, the problem is likely codec support in the player, not file damage. Try VLC, which supports nearly every codec in common use, before concluding the file is broken.

Container identified, no duration. The index is missing or damaged. In MP4 this is the classic "moov atom not found" failure: the media bytes are present but nothing maps them. In MKV it usually means the file was truncated mid-write. Either way, the media is often recoverable — move to the Corrupt Video Checker for a verdict on your specific case.

File is very small (under 1 MB). Either the recording never actually started, or the file is a header fragment. Check the recording path in OBS settings and the disk's free space at the time of recording. The original cannot be recovered from this file, but the next recording can be protected.

Unrecognized container. The extension and the contents disagree. The file may have been renamed, downloaded incompletely, or written by software that produced a non-standard container. Renaming the extension to match the detected container often fixes playback.

Common scenarios, decoded

Note for video-inspector: The following scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — typical situations users bring to an inspector, not documented case files.

The renamed file. A colleague sends you final_v2.mp4, but the inspector says it is actually MKV. Somewhere along the way the file was renamed without being converted. The fix is either a proper remux (ffmpeg -i final_v2.mp4 -c copy final_v2.mkv) or simply renaming the extension back — players mostly go by content, but editors often go by extension.

The 0-byte mystery. The file exists in the folder, the name is right, the size is 0 B. The recorder opened the file but never wrote to it — usually a permissions problem, a full disk, or a path that vanished mid-session (a disconnected external drive, an unmounted network share). No inspector can recover zero bytes; the fix is preventive, aimed at the next session.

The duration mismatch. A file that should hold 90 minutes reports 12. This usually means the recording was interrupted and the index reflects only the completed portion. In MKV, a remux often recovers the orphaned clusters beyond the recorded duration. In MP4, the missing tail means missing index entries, and a reference-file rebuild is the next step.

The editor won't import it. The inspector shows healthy metadata, but Premiere or Resolve refuses the file. The culprit is often an exotic codec profile (High 10 instead of High, for example) or a variable frame rate that the editor's importer misreads. Transcoding to an edit-friendly intermediate (ProRes or DNxHR) solves almost all of these without visible quality loss.

Inspector versus checker versus repair tool — which to use when

These three tools on this site form a diagnosis-to-fix pipeline, and using them in order saves time:

1. Video Inspector answers "what is this file?" — container, streams, duration, size. Use it first, on any file whose provenance or state you're unsure of.
2. Corrupt Video Checker answers "is it broken, and how badly?" — it takes your symptoms and returns a verdict with a recommended action. Use it when a file won't open or plays incorrectly.
3. Repair Command Generator answers "what command do I run?" — given the diagnosis, it produces the safest FFmpeg command with warnings about what it will and won't do. Use it last, right before you act.

Each step narrows the problem. Skipping straight to repair commands without a diagnosis is how people re-encode healthy files or run the wrong fix on a damaged one.

What the inspector cannot do

Honesty about limits is part of the tool. It cannot:

• Repair anything — it only reads and reports.
• Guarantee playability — a structurally valid file can still contain a corrupted stream the browser doesn't catch at the header level.
• Read every codec — unusual or proprietary codecs may report as unknown, which is information in itself.
• Verify checksums or bit-level integrity — for archival verification, use a dedicated checksum tool alongside this one.

If the inspector's verdict leaves you uncertain, that is exactly what the checker and repair generator downstream are for.

How this connects to WeaverClip — without bullshit

Inspection is triage; it tells you what you have. What it cannot do is prevent the situation that makes you need it. WeaverClip's recording pipeline is built around not needing a rescue: one-minute segments are verified against the vault before the local copy is released, so a crashed app or a dead disk costs you a minute, not a session. The inspector remains genuinely useful for everything that arrives from elsewhere — client files, old archives, phone footage — and it stays free, in-browser, and upload-free whether or not you ever create an account.

FAQ

Does anything get uploaded when I drop a file? No. The file is read by your browser's File API and never transmitted. Disconnect your network and it works identically.

Why does my MP4 show no duration but my MKV does? MP4 stores its index at the end of the file (or at the start, only after a finalization pass). If recording stopped uncleanly, the index was never written. MKV writes index information incrementally, so even an interrupted file usually reports its duration.

The inspector says H.264 "assumed" — why? Browsers expose resolution and duration reliably but do not always expose codec details through the HTML5 video element. When the codec cannot be confirmed, the inspector says so rather than guessing silently. Run ffprobe for a definitive codec read.

Can I inspect files on my phone? Yes, in a mobile browser. The File API works on modern iOS Safari and Android Chrome, though very large files may exceed mobile memory limits.

What file size can it handle? There is no hard cap imposed by the tool; the limit is your browser's memory and the fact that only header bytes are read. In practice, multi-gigabyte files inspect fine because the tool never loads the whole file.

It says my file is healthy but it won't play anywhere. Try VLC first — it ships its own decoders for nearly every format. If VLC also fails, the damage is deeper than the header and the Corrupt Video Checker is your next stop.

A field-by-field reading guide

Each value the inspector returns carries diagnostic weight. Here is how to read them like someone who has triaged a lot of recordings.

Container. The wrapper, identified by file signature rather than extension. If the detected container disagrees with the filename, someone renamed the file without converting it — and the fix is usually to rename it back, because players read content while some editors read extensions. MP4 and MOV share the same box structure; MKV and WebM share EBML; TS and FLV are streaming containers that OBS writes less often.

Resolution. What the file actually holds, not what the camera claimed. A recording that says 1280×720 when you set 1080p means OBS downscaled under load or the base canvas was misconfigured — worth knowing before you blame the encoder for softness.

Duration. The single most diagnostic field. Present and plausible means the index landed and the file closed cleanly. Missing or infinite on an MP4 means the moov atom never wrote — the classic crash signature. Present on an MKV after a crash means the incremental index survived, which is the container doing its job.

File size. Cross-check it against duration: size divided by hours divided by 0.45 gives the effective total Mbps. A 90-minute file at 4.2 GB implies about 7.5 Mbps — plausible for 1080p with audio. A 90-minute file at 400 MB implies 0.7 Mbps, which means the encoder starved badly or the recording is mostly blank frames. The arithmetic catches corrupted-looking files that are actually just under-recorded.

Video codec, where reported. Browsers expose codec details inconsistently — the inspector says "assumed" rather than guess silently. When codec matters (an editor refusing to import, a platform rejecting an upload), the definitive read is ffprobe, and the inspector tells you the exact command.

Audio streams. The inspector surfaces audio codec and channel layout where the browser reports them. Two values matter for recording work: sample rate and track count. A 44.1 kHz capture in a 48 kHz project will resample on import and can drift over long sessions — the audio sync calculator on this site quantifies that drift in milliseconds and frames. Multi-track layouts (six-track esports recordings, separate mic and Discord buses) survive in MKV and MP4 alike, but only if the container closed; a crashed MP4 loses the track map with the rest of the index.

Color and range metadata. Less commonly inspected, but it explains a classic complaint: footage that looks washed out after upload. A full-range recording tagged incorrectly plays as lifted blacks on some platforms. The browser probe does not report color space, so treat this as an ffprobe follow-up (-show_entries stream=color_range,color_space,color_primaries) whenever a clip looks flatter than the live preview.

Three files, decoded — hypothetical, labeled

Note for video-inspector: The three readings below are hypothetical examples (illustrative, not sourced case studies) for this specific tool — typical files users drop into an inspector, with the interpretation a human expert would give each field.

File A — `episode_042.mp4`, 4.1 GB, duration 01:29:51, 1920×1080. Every field lines up: container MP4, duration present, size consistent with roughly 6 Mbps over 90 minutes. Verdict: healthy, closed cleanly. The actionable output is not a repair — it is confidence. Archive it, and if this is a podcast series, note that the recording path is doing its job so the next session can use the same settings.

File B — `stream_saturday.mp4`, 22 GB, duration unknown. The file is big enough to hold the session, but the browser cannot read a duration. That combination — plausible size, missing index — is the moov failure: OBS wrote media for hours and died before the one-pass index write at Stop. The inspector's diagnosis names it and points at the rebuild path: a reference file from the same settings plus Untrunc or Recover_MP4. The media bytes are almost certainly intact; what is missing is the map, and maps can be rebuilt. Do not re-encode this file — that would destroy what is recoverable.

File C — `webinar_take3.mkv`, 850 MB, duration 00:41:12, 1920×1080. MKV with a readable duration after what the user describes as a crash. The incremental index survived; the file likely plays with a warning at the tail where the last cluster was cut mid-write. The inspector's MKV diagnosis applies: a one-line remux (ffmpeg -i in.mkv -c copy out.mkv) rebuilds the seek index losslessly and yields a fully playable file. Total loss from the crash: the final few seconds, not 41 minutes. This is the outcome MKV exists to provide, and the file that converts skeptics.

Size and duration cross-checking — the arithmetic that catches lies

Files lie in two directions: a duration that claims more than the bytes can hold, and a size that implies quality the bitrate never delivered. Both are catchable with one division.

Expected size = total Mbps × 0.45 × hours. Compute it from what the recording should have been (your OBS settings), then compare to what the file reports. Three outcomes:

• Within 15 percent: normal. CQP variance, audio tracks, muxing overhead all live in this band.
• File is much smaller than expected: the encoder ran starved or dropped content. Check the stats dock history if you still have it; otherwise the footage is what it is — softer than intended, but structurally fine.
• File is much larger than expected: you recorded at a higher setting than you thought (a profile switch nobody remembered), or dual-canvas was on. Larger is never corruption; it is a settings mystery, and the inspector's bitrate readout solves it.

The reverse cross-check works when duration is missing but size exists: divide size by the expected GB-per-hour to estimate how much footage is actually in the file. A 22 GB file at 5.5 GB/h holds about four hours — which tells you the crash cost minutes, not the whole stream, before you have recovered a single frame.

When to reach for ffprobe instead

The browser probe is fast, private, and sufficient for triage. Three situations deserve the deeper tool:

An editor refuses the file but it plays fine. Variable frame rate is the usual suspect — phones and some capture cards write VFR, which players tolerate and NLE importers do not. ffprobe -show_entries stream=avg_frame_rate,r_frame_rate shows both; if they disagree materially, transcode to constant frame rate before importing.

You need the codec profile and level. Compatibility failures (an old player, a hardware decoder, a platform re-encode) live at the profile/level layer, which browsers do not expose. ffprobe -show_streams prints it; paste the confusing line into the Repair Command Generator and it translates.

You are verifying an archive. The inspector reads headers; archive verification wants checksums. ffprobe plus a hash of the file is the minimum bar for "this copy is the master" — and byte-for-byte verification against a vault copy is the real one.

How this connects to WeaverClip — without bullshit

The inspector answers "what is this file?" It cannot answer "is my recording safe?" — that question belongs to whatever happens between the disk and the archive. WeaverClip's part of the answer is verification: each minute of a recording is checked against the vault byte for byte before the local copy is released, so the files you eventually drop into this tool already carry a provenance, and a healthy verdict means something stronger than "the header parsed." For everything that arrives from elsewhere — client uploads, old archives, phone footage — the inspector stays free, local, and account-free, because triage should never cost you a signup.

FAQ — the rest of the questions

Why does my MKV show dimensions but my MP4 shows nothing after the same crash? MKV writes its index as it records; MP4 writes one index at the end. The crash erased the MP4's map but left the MKV's intact. Same power failure, opposite outcomes — that difference is the entire argument for recording MKV.

Can the inspector tell me if the file is repairable? It can tell you which failure class the file is in, and each class has a known repair path — that is what the diagnosis panel does. For the actual verdict and the command, hand the result to the Corrupt Video Checker and the Repair Command Generator; the three tools are a pipeline, and the inspector is step one.

Does inspecting a file change it? No. The tool reads header bytes through your browser's File API and writes nothing. The original is untouched; every downstream repair step works on a copy anyway.

The codec says "assumed" — should I worry? Only if codec compatibility is your actual problem (editor import, platform upload). For crash triage, container and duration carry the whole diagnosis, and those are definitive.

What about files from a phone or camera? They inspect the same way. The interesting failure there is not corruption but VFR and rotation metadata — both visible to ffprobe, both common reasons an "healthy" phone file imports sideways into an editor.

How do I inspect a file that is still being recorded? You cannot, usefully — an open file's header is mid-write, and for MP4 the index has not landed yet, so the inspector would report a false corruption. Inspect after the recorder closes the file. If you need visibility during a session, that is what a segmented recording pipeline is for: each closed segment is a complete, inspectable file the moment it finishes writing.

Two files with identical metadata — are they identical? No. Metadata describes structure, not content. Two files can share container, codec, resolution, and duration and hold completely different frames. If you need to know whether two files are the same recording, compare checksums — that is a byte-level question the inspector deliberately does not answer.