Web browser

What has to happen before a web page will give you its file

You can see the video. It is playing, right there, in the web browser. So why is there no way to keep it? The answer is that a web page rarely hands over a file — it hands over instructions, and the file the browser assembles from them may not exist as a single thing at all.

6 min read Updated 29 July 2026

FoxDL

Four ways a page delivers video, only one of which is a file

The oldest and simplest is a direct file: the page points at an address ending in .mp4 and the browser fetches it. If you can find that address, you have the file. This is still how most smaller sites, forums, news outlets and file hosts work.

The second is adaptive streaming — HLS or DASH. The page loads a playlist that lists hundreds of short segments at several quality levels, and the player stitches them together as it goes, switching quality when your connection changes. There is no single file to find. Saving it means fetching every segment and rebuilding a file from them.

The third is a blob URL. The page has already fetched the data with JavaScript and handed the player a reference to something living in the browser’s own memory. The address you can see (blob:https://…) is meaningless outside that page and that session — it cannot be opened, shared or downloaded, and this trips up most naive “video finders”.

The fourth is protected content: encrypted segments played through a DRM system, where the decryption key is issued to the browser under conditions that explicitly forbid keeping a copy. This is not an obstacle to be worked around; it is the mechanism a licence agreement is built on, and no legitimate tool defeats it.

How a web browser notices there is something to save

An in-app web browser that offers to save what it finds is doing several jobs at once. Each catches a case the others miss.

Reading the page’s media elements
Walking the document for <video>, <audio> and <source> tags and reading their addresses. Catches the direct-file case immediately, misses everything built by JavaScript after the page loaded.
Looking inside shadow DOM
Modern players are custom elements whose internals are deliberately sealed off from the page. A search that stops at the ordinary document sees an empty box where the video is.
Watching what the page actually requested
The browser knows every resource a page fetched. A media file that was loaded — regardless of which script asked for it, or when — shows up here even if nothing in the visible page points at it.
Sniffing the response type
A URL ending in .php can return a video, and a URL ending in .mp4 can return an error page. The Content-Type the server actually sent is what tells you which — extensions are a guess.

What saving from a page looks like when it works

The order matters. Most failures come from skipping the second step and starting a four-gigabyte transfer of a login page.

  1. Play a second of the media first

    Many pages load nothing until playback starts. Two seconds of playing is often the difference between an empty list of candidates and a full one.

  2. Check what the candidate actually is

    Before committing, look at the reported size and type. A “film” of 14 KB is an HTML page. A type of text/html where you expected video/mp4 means you have the wrong link.

  3. Pick the quality you want

    A stream usually offers several. The highest is not always the right answer on a phone, where the difference is invisible and the storage is not.

  4. Let the session carry across

    Protected links check who is asking: the cookies from your logged-in session, the page that referred you, sometimes the browser identity. A download started without those gets a 403 even though the page played fine.

  5. Verify what landed

    Open it. A file that plays for two seconds and stops was truncated — usually an expired link — and is worth restarting rather than keeping.

What an in-app web browser has to get right

Beyond finding the media, these are the things that decide whether the download actually completes.

  • Carry the session through to the download

    Cookies, referer and user agent must travel with the request. Without them a protected link resolves in the page and fails in the downloader.

  • Keep those credentials out of storage

    Session cookies are as good as a password for the length of the session. They belong in memory for the duration of the transfer and nowhere else — not in a database, not in a log.

  • Refuse to hand the link to another app

    iOS will happily open a tapped link in a different app if it claims that domain. A web browser meant for saving media has to cancel and reissue the navigation itself, or the page you wanted disappears into somebody else’s app.

  • Trim the page before it renders

    A content blocker is not just about advertising here — fewer trackers and overlays means fewer false candidates in the media list.

  • Handle documents as well as video

    PDFs, ZIPs and Office files are the other half of what people save from the web, and they should land in the same library as everything else.

Questions people ask

Why can Safari not do this on its own?

Safari does download files — it has since iOS 13. What it does not do is inspect a page for media that is being streamed rather than linked, or rebuild a segmented stream into a file. It is a web browser, and that work belongs to a download manager.

What is a blob URL and why can I not download it?

It is a handle to data the page already holds in memory. It has no existence outside that tab, so pasting it anywhere produces nothing. The underlying media was fetched from somewhere real, and that address — not the blob — is the one worth finding.

The page plays fine but the download gets a 403. Why?

The download request arrived without the things the page had: your session cookie, the referring page, sometimes a matching browser identity. Servers use exactly that combination to distinguish a viewer from a scraper.

Can everything be saved?

No, and that is by design. Content protected with DRM is encrypted with keys issued under a licence that forbids keeping it. Some sites also sign every segment individually with short-lived tokens. Both are working as intended.

FoxDL

The web browser inside FoxDL

It is a normal tabbed web browser whose job is getting things into your library rather than being your everyday browser.

  • Six detection channels, including shadow DOM and the record of what the page actually requested, so a player built entirely in JavaScript is still visible.
  • The real type is sniffed from the response rather than guessed from the extension, and blob: candidates that cannot be fetched are filtered out instead of being offered and failing.
  • Cookies, referer and user agent are carried through to the download so a protected link resolves — and none of them is ever written to disk.
  • A content blocker trims the page before it renders.
  • PDFs, ZIPs and documents save into the same library as media, with one tap.
  • Tabs, bookmarks and a start page of your own shortcuts.

FoxDL provides no content of its own. What you save is what you brought, and you are responsible for having the right to keep it.

Questions people ask about this

All questions

Keep reading

What a download manager does that a web browser will not

Why transfers stop when you switch apps, what resuming really requires, and how streams become files.

What a media app on your phone can see, and what it should never send

What a media app can see, how to read a privacy label, and why a lock is not encryption.

Where your files actually live on an iPhone, and who can see them

The sandbox, where downloads actually go, and why renaming a file breaks so many apps.

Your library, finally in one place.

Free to download. No account, no sign-up, and the whole feature set is in the free version.

Download on the App Store