Downloading a URL that redirects

A redirect is a forwarding instruction

When your browser asks for a URL, the server answering has two choices. It can send back the page, or it can reply with an instruction that says the thing you want lives at a different address. Your browser follows that instruction without asking you, which is why the address in your bar at the end of a click is frequently not the one you clicked.

Vidzilla does the same thing. It requests the URL you pasted, follows each forwarding instruction it receives, and reads whatever page it lands on. One hop or four hops makes no difference to the result.

Why so many video URLs hop at all

Forwarding is ordinary plumbing rather than a sign of anything being wrong. These are the reasons you meet most often.

• A share button hands out a wrapper address so the site can count how often the link travels.
• A site that once used an old domain name forwards every old address to the current one.
• A mobile address forwards to the desktop version of the same page, or the reverse.
• A campaign or newsletter link passes through a tracking host that records the click and moves you on.
• The video file itself sits on a delivery network, and the page forwards playback to a signed address on that network.

Reading where a URL finally lands

The address bar after the dust settles is the honest one. Open the URL in a browser tab, wait until the video is on screen and playing, then look at the bar. That address is what the page actually resolved to.

Compare it with what you started with. A different host, a longer path, or an identifier appearing where there was none tells you a hop happened. If the final address opens the video on its own in a new tab, it works here.

When a hop stops at a page instead of a video

This is the one case that genuinely breaks a download. Some chains end at a page that is not the video: an interstitial with a countdown, a consent or cookie notice that has to be accepted, an age confirmation, a region notice, or a sign-in prompt. The forwarding stops there and waits for a human.

Vidzilla reaches that page, finds no video being served on it, and returns an empty result. That is an accurate report of the address rather than a fault. The fix is to become the human: open the URL yourself, clear whatever the page is asking for, and once the video is playing, copy the address you have ended up on and paste that.

Signed addresses that expire

Some hops finish at an address containing a long block of random characters and an expiry stamp. Those are issued for one viewer for a short window, and they stop working shortly afterwards, sometimes within minutes.

If you copy one of those and paste it here later, the answer is empty because the address itself has lapsed. Go back to the page address of the video, the one a person would share, and paste that instead. Vidzilla requests a fresh copy of whatever the page is serving at that moment.

What to paste when you have a choice

Given a wrapper address and the address it forwards to, either one works, so use whichever you have. Where a link came out of an email or a chat message and you are unsure what it is attached to, opening it once and copying the resulting address removes the guesswork.

A URL that redirects to a channel, a feed, or a search page is a different problem from a redirect that fails. The chain worked; the destination has many videos on it and no single file to hand over. Open one video on that destination and copy its address.

Related pages

• Reading the parts of a web address
• What happens between Analyze and the file
• Trying a site you have not used before
• Which sites Vidzilla reads