Webbrowser

Was passieren muss, bevor eine Webseite dir ihre Datei gibt

Du siehst das Video. Es läuft, genau dort, im Webbrowser. Warum gibt es dann keinen Weg, es zu behalten? Weil eine Webseite selten eine Datei herausgibt — sie gibt Anweisungen heraus, und die Datei, die der Browser daraus zusammensetzt, existiert vielleicht gar nicht als einzelnes Ding.

6 Min. Lesezeit Aktualisiert 29. Juli 2026

FoxDL

Vier Wege, wie eine Seite Video ausliefert — nur einer davon ist eine Datei

Der älteste und einfachste ist eine direkte Datei: Die Seite zeigt auf eine Adresse mit der Endung .mp4, und der Browser lädt sie. Findest du diese Adresse, hast du die Datei. So funktionieren die meisten kleineren Sites, Foren, Nachrichtenportale und Filehoster immer noch.

Der zweite ist adaptives Streaming — HLS oder DASH. Die Seite lädt eine Playlist mit Hunderten kurzer Segmente in mehreren Qualitätsstufen; der Player setzt sie unterwegs zusammen und wechselt die Qualität, wenn sich deine Verbindung ändert. Es gibt keine einzelne Datei zum Finden. Speichern heißt: jedes Segment holen und daraus eine Datei neu aufbauen.

Der dritte ist eine Blob-URL. Die Seite hat die Daten bereits per JavaScript geholt und dem Player einen Verweis auf etwas gegeben, das nur im Speicher des Browsers lebt. Die Adresse, die du siehst (blob:https://…), ist außerhalb dieser Seite und dieser Sitzung bedeutungslos — sie lässt sich nicht öffnen, teilen oder herunterladen, und daran scheitern die meisten naiven „Video-Finder“.

Der vierte ist geschützter Inhalt: verschlüsselte Segmente über ein DRM-System, bei dem der Entschlüsselungsschlüssel unter Bedingungen ausgegeben wird, die das Behalten einer Kopie ausdrücklich verbieten. Das ist kein Hindernis zum Umgehen; es ist der Mechanismus, auf dem eine Lizenzvereinbarung aufbaut — und kein legitimes Werkzeug knackt ihn.

Wie ein Webbrowser merkt, dass es etwas zum Speichern gibt

Ein In-App-Webbrowser, der anbietet, was er findet zu speichern, macht mehrere Jobs gleichzeitig. Jeder fängt einen Fall ab, den die anderen verpassen.

Die Medien-Elemente der Seite lesen
Das Dokument nach <video>, <audio> und <source> durchsuchen und ihre Adressen lesen. Fängt den Fall der direkten Datei sofort ab, verpasst alles, was JavaScript nach dem Laden der Seite erst gebaut hat.
In den Shadow DOM schauen
Moderne Player sind Custom Elements, deren Innenleben absichtlich von der Seite abgeschottet ist. Eine Suche, die beim normalen Dokument stehen bleibt, sieht dort, wo das Video ist, eine leere Box.
Beobachten, was die Seite wirklich angefordert hat
Der Browser kennt jede Ressource, die eine Seite geholt hat. Eine Mediendatei, die geladen wurde — egal welches Skript sie wann angefordert hat — taucht hier auf, selbst wenn auf der sichtbaren Seite nichts darauf zeigt.
Den Antworttyp sniffen
Eine URL mit der Endung .php kann ein Video liefern, und eine mit .mp4 kann eine Fehlerseite sein. Der Content-Type, den der Server wirklich geschickt hat, sagt dir, was es ist — Dateiendungen sind nur eine Vermutung.

So sieht Speichern von einer Seite aus, wenn es funktioniert

Die Reihenfolge ist entscheidend. Die meisten Fehler entstehen, wenn man den zweiten Schritt überspringt und einen vier Gigabyte großen Transfer einer Login-Seite startet.

  1. Zuerst eine Sekunde der Medien abspielen

    Viele Seiten laden nichts, bevor die Wiedergabe startet. Zwei Sekunden Abspielen entscheiden oft zwischen einer leeren Kandidatenliste und einer vollen.

  2. Prüfen, was der Kandidat wirklich ist

    Bevor du dich festlegst: Größe und Typ anschauen. Ein „Film“ mit 14 KB ist eine HTML-Seite. Ein Typ text/html, wo du video/mp4 erwartet hast, bedeutet: falscher Link.

  3. Die Qualität wählen, die du willst

    Ein Stream bietet meist mehrere. Die höchste ist am Handy nicht immer die richtige — der Unterschied ist unsichtbar, der Speicherplatz nicht.

  4. Die Sitzung mitnehmen lassen

    Geschützte Links prüfen, wer fragt: die Cookies deiner eingeloggten Sitzung, die Seite, die dich verwiesen hat, manchmal die Browser-Identität. Ein Download ohne das bekommt einen 403, obwohl die Seite fein abgespielt hat.

  5. Prüfen, was angekommen ist

    Öffnen. Eine Datei, die zwei Sekunden spielt und dann stoppt, war abgeschnitten — meist ein abgelaufener Link — und lohnt einen Neustart mehr als Aufbewahren.

Was ein In-App-Webbrowser richtig machen muss

Über das Finden der Medien hinaus entscheiden diese Punkte, ob der Download wirklich durchläuft.

  • Die Sitzung bis zum Download mitnehmen

    Cookies, Referer und User-Agent müssen mit der Anfrage mitgehen. Ohne sie löst sich ein geschützter Link auf der Seite auf und scheitert im Downloader.

  • Diese Zugangsdaten nicht speichern

    Sitzungs-Cookies sind für die Dauer der Sitzung so gut wie ein Passwort. Sie gehören für die Dauer des Transfers in den Speicher — und nirgendwo sonst: nicht in eine Datenbank, nicht in ein Log.

  • Den Link nicht an eine andere App weiterreichen

    iOS öffnet einen angetippten Link gerne in einer anderen App, wenn die die Domain beansprucht. Ein Webbrowser zum Speichern von Medien muss die Navigation selbst abbrechen und neu auslösen — sonst verschwindet die gewünschte Seite in fremder App.

  • Die Seite vor dem Rendern kürzen

    Ein Inhaltsblocker geht hier nicht nur um Werbung — weniger Tracker und Overlays bedeuten weniger Fehlkandidaten in der Medienliste.

  • Dokumente ebenso behandeln wie Video

    PDFs, ZIPs und Office-Dateien sind die andere Hälfte dessen, was Leute vom Web speichern, und sie sollten in derselben Bibliothek landen wie alles andere.

Fragen, die Leute stellen

Warum kann Safari das nicht von allein?

Safari lädt Dateien herunter — seit iOS 13. Was es nicht tut: eine Seite nach Medien durchsuchen, die gestreamt statt verlinkt werden, oder einen segmentierten Stream zu einer Datei zusammenbauen. Es ist ein Webbrowser, und diese Arbeit gehört zu einem Download-Manager.

Was ist eine Blob-URL und warum kann ich sie nicht herunterladen?

Es ist ein Handle auf Daten, die die Seite bereits im Speicher hält. Außerhalb dieses Tabs existiert sie nicht — Einfügen irgendwo ergibt nichts. Die eigentlichen Medien kamen von einer echten Adresse, und die — nicht der Blob — ist die, die sich zu finden lohnt.

Die Seite spielt fein, aber der Download bekommt einen 403. Warum?

Die Download-Anfrage kam ohne das an, was die Seite hatte: dein Sitzungs-Cookie, die verweisende Seite, manchmal eine passende Browser-Identität. Server nutzen genau diese Kombination, um Zuschauer von Scrapern zu unterscheiden.

Lässt sich alles speichern?

Nein, und das ist Absicht. DRM-geschützter Inhalt ist mit Schlüsseln verschlüsselt, die unter einer Lizenz ausgegeben werden, die das Behalten verbietet. Manche Sites signieren auch jedes Segment einzeln mit kurzlebigen Tokens. Beides funktioniert wie vorgesehen.

FoxDL

Der Webbrowser in FoxDL

Es ist ein ganz normaler Tab-Webbrowser, dessen Job es ist, Dinge in deine Bibliothek zu bekommen — nicht dein Alltagbrowser zu sein.

  • Sechs Erkennungskanäle, inklusive Shadow DOM und dem Protokoll dessen, was die Seite wirklich angefordert hat — damit ein rein in JavaScript gebauter Player trotzdem sichtbar bleibt.
  • Der echte Typ wird aus der Antwort gesnifft, nicht aus der Dateiendung geraten; blob:-Kandidaten, die sich nicht holen lassen, werden herausgefiltert statt angeboten und zu scheitern.
  • Cookies, Referer und User-Agent werden zum Download mitgenommen, damit ein geschützter Link auflöst — und keines davon wird je auf die Festplatte geschrieben.
  • Ein Inhaltsblocker kürzt die Seite vor dem Rendern.
  • PDFs, ZIPs und Dokumente landen mit einem Tippen in derselben Bibliothek wie Medien.
  • Tabs, Lesezeichen und eine Startseite mit deinen eigenen Shortcuts.

FoxDL liefert keinen eigenen Inhalt. Was du speicherst, hast du mitgebracht — und du bist dafür verantwortlich, das Recht zu haben, es zu behalten.

Häufige Fragen dazu

Alle Fragen

Weiterlesen

Deine Bibliothek, endlich an einem Ort.

Kostenlos laden. Kein Konto, keine Anmeldung — der volle Funktionsumfang steckt in der Gratisversion.

Laden im App Store