How MediaDocks works

The first thing that happens to a pasted URL is that it gets taken apart rather than trusted. The string is length-checked, parsed into a real URL object, and matched against the set of hosts the service knows how to handle. A URL that does not parse, or that points somewhere unexpected, is rejected at this boundary before a single outbound byte is sent.

Short links need an extra step. A youtu.be, pin.it or fb.watch address does not contain the identifier the extractor needs, so it has to be followed to its destination. Those redirects are followed deliberately rather than blindly: each hop is re-validated against the same host allow-list, which stops a short link from being used to point the server at an address it would never accept directly.

Only once the final URL is known and permitted does the extractor run. This ordering matters more than it sounds — a media service that fetches first and validates second is a server-side request forgery waiting to happen.

With a validated URL, the extractor queries the platform for the renditions it publishes for that one item. What comes back is a list of concrete streams, each with its own container, codec, resolution, bitrate and file size. That list is what you see in the format picker — it is read from the source, not generated from a template.

This is why two links from the same platform can offer different choices. A clip uploaded at 720p exposes no 1080p rendition, so none is listed. Showing one anyway would mean upscaling: a larger file carrying exactly the same detail, which is a worse outcome dressed up as a better one.

Metadata arrives in the same pass — title, creator, duration and thumbnail — which is why the result card can show you what you are about to download before you commit to it. Duration is also where a source longer than the one-hour extraction ceiling gets caught and reported early, rather than after you have waited through a doomed transfer.

Below roughly 360p, most platforms still serve a progressive file — one container holding both picture and sound. Those downloads are close to a straight pass-through, which is why they feel instant.

Above that, the model changes. YouTube and several others adopt DASH, publishing video and audio as entirely separate streams so a player can switch quality on the fly without re-buffering the soundtrack. It is an excellent design for streaming and an inconvenient one for downloading, because neither stream on its own is a usable file: the video track is silent and the audio track has no picture.

To hand you one playable file, the server fetches both streams and muxes them — interleaving the two into a single MP4 container using FFmpeg. Muxing is not re-encoding. The compressed frames are copied across untouched, so there is no generational quality loss; only the wrapper changes. What it does cost is time, because a meaningful portion of both streams has to be on hand before output can begin. A ten-minute 1080p video typically takes about two minutes end to end, and that gap between picking 1080p and seeing the save dialog is almost entirely this step.

Audio-only requests skip the video stream altogether. That is why extracting an MP3 from a long video finishes far quicker than any video rung — there is simply far less to move. MP3 output is the one place a genuine re-encode happens, and the available bitrates are capped at whatever the source track actually carries, because transcoding 128 kbps up to 320 kbps produces a bigger file and not one extra decibel of detail.

Output is piped to your browser as it is produced rather than assembled into a finished file and then served. The practical effect is that the download starts moving as soon as there is something to send, and the server never needs to hold a complete copy of your media.

Whatever temporary working files the muxer needed live in a directory scoped to that single request, and that directory is removed when the request ends — on the error path as well as the success path. There is no media library, no cache of completed downloads and no archive to browse, which is the whole reason the privacy claim on this site is a structural fact rather than a promise.

The descriptor produced when a link resolves is valid for thirty minutes. After that it expires and the URL has to be pasted again. A short window is what makes it safe to keep nothing: there is no long-lived handle pointing at anything.