How does MediaPeek inspect media metadata from a URL without downloading the full file?

MediaPeek reads only the parts of a file it needs to identify its metadata, using byte-range HTTP requests instead of downloading the whole file. You give it an HTTP/HTTPS URL or a public Google Drive file or folder, and it parses the metadata in your browser through a WebAssembly build of the MediaInfo library. That means large files can be inspected without waiting for a full transfer, and the analysis runs near you at the edge rather than on a central server.

How partial fetching works

The core mechanism is the HTTP Range header. Instead of requesting the entire file, MediaPeek asks the host for specific byte ranges — typically the container headers at the start of the file and the index or footer at the end. Media metadata such as codec, resolution, duration, and track layout is usually described in those structures, so the tool can report it without touching the media payload in between.

The practical effect: a multi-gigabyte video can be inspected in seconds, and bandwidth use stays small. The trade-off is that the source must support range requests. A plain static file server or Google Drive's public file endpoints generally do; a URL that streams from a server which ignores Range headers, or one behind authentication, may not work.

What it accepts

For archives, MediaPeek looks inside without extracting the full file and keeps the archive name visible so you can tell which file a result came from.

The metadata engine

Parsing is done by mediainfo.js v0.3.7, a WebAssembly port of MediaInfoLib v25.10 (copyright MediaArea.net SARL). Because it runs in WebAssembly, the analysis happens in the browser environment close to the user rather than being uploaded to a backend. MediaPeek states that it does not store the content.

This matters for two reasons. First, the same library that powers desktop MediaInfo produces the results, so field names and format detection should look familiar. Second, the file itself is never fully transferred to a server for analysis — only the byte ranges needed for parsing are fetched.

Sharing and export

Results can be exported as Object JSON, Text, HTML, or XML, depending on whether you need something human-readable or machine-parseable. Sharing uses encrypted links via PrivateBin: the key stays in the URL fragment, and MediaPeek does not store the content. Anyone with the full link can decrypt the result; without the fragment, the shared data is not readable.

When this approach fits — and when it doesn't

Use MediaPeek when you have a direct, publicly reachable URL and want a quick read on codec, resolution, duration, or track details without pulling the file down. It is also useful for peeking inside ZIP or TAR archives to see what media they contain before extracting.

It is a poor fit when the URL requires login, when the host does not honor range requests, or when you need frame-level analysis rather than container metadata. In those cases you would need to download the file and inspect it locally.

Verifying a result

1. Open the app and paste an HTTP/HTTPS URL or a public Google Drive link.
2. Confirm the fetch completes and metadata appears — a failure here usually points to a blocked range request or a private resource.
3. Cross-check a known field (for example, duration or resolution) against the file's own player or ffprobe output.
4. Export as JSON if you need to compare fields programmatically.

The most common snag is a URL that looks public but sits behind a redirect or token check; if the fetch fails, test the same URL with a direct curl -r 0-1023 request to see whether range access is actually permitted.