Webbläsare

Vad som måste hända innan en webbsida ger dig sin fil

Du kan se videon. Den spelas upp, precis där, i webbläsaren. Så varför finns det inget sätt att behålla den? Svaret är att en webbsida sällan lämnar över en fil — den lämnar över instruktioner, och filen webbläsaren sätter ihop från dem kanske inte existerar som en enda sak alls.

6 min läsning Uppdaterad 29 juli 2026

FoxDL

Fyra sätt en sida levererar video, bara ett av dem är en fil

Det äldsta och enklaste är en direktfil: sidan pekar mot en adress som slutar på .mp4 och webbläsaren hämtar den. Om du kan hitta den adressen har du filen. Så här fungerar fortfarande de flesta mindre webbplatser, forum, nyhetssajter och filvärdar.

Det andra är adaptiv strömning — HLS eller DASH. Sidan läser in en spellista som listar hundratals korta segment på flera kvalitetsnivåer, och spelaren syr ihop dem allteftersom, och växlar kvalitet när din anslutning ändras. Det finns ingen enskild fil att hitta. Att spara den innebär att hämta varje segment och bygga om en fil från dem.

Det tredje är en blob-URL. Sidan har redan hämtat datan med JavaScript och gett spelaren en referens till något som lever i webbläsarens eget minne. Adressen du kan se (blob:https://…) är meningslös utanför den sidan och den sessionen — den kan inte öppnas, delas eller laddas ner, och det här snubblar de flesta naiva "videohittare".

Det fjärde är skyddat innehåll: krypterade segment spelade genom ett DRM-system, där avkrypteringsnyckeln utfärdas till webbläsaren under villkor som uttryckligen förbjuder att behålla en kopia. Det här är inget hinder att ta sig runt; det är mekanismen ett licensavtal är byggt på, och inget legitimt verktyg besegrar det.

Hur en webbläsare märker att det finns något att spara

En webbläsare i en app som erbjuder att spara vad den hittar gör flera jobb samtidigt. Var och en fångar ett fall de andra missar.

Läsa sidans medieelement
Att gå igenom dokumentet efter <video>-, <audio>- och <source>-taggar och läsa deras adresser. Fångar direktfil-fallet omedelbart, missar allt byggt av JavaScript efter att sidan laddats.
Titta inuti shadow DOM
Moderna spelare är anpassade element vars insidor avsiktligt är förseglade från sidan. En sökning som stannar vid det vanliga dokumentet ser en tom ruta där videon är.
Bevaka vad sidan faktiskt begärt
Webbläsaren känner till varje resurs en sida hämtat. En mediefil som laddades — oavsett vilket skript som begärde den, eller när — dyker upp här även om inget i den synliga sidan pekar på den.
Sniffa svarstypen
En URL som slutar på .php kan returnera en video, och en URL som slutar på .mp4 kan returnera en felsida. Content-Type servern faktiskt skickade är vad som berättar vilket — filändelser är en gissning.

Hur det ser ut när sparande från en sida faktiskt fungerar

Ordningen spelar roll. De flesta misslyckanden kommer från att hoppa över det andra steget och starta en fyra gigabyte-överföring av en inloggningssida.

  1. Spela en sekund av mediet först

    Många sidor laddar inget förrän uppspelning startar. Två sekunders spelning är ofta skillnaden mellan en tom lista med kandidater och en full en.

  2. Kontrollera vad kandidaten faktiskt är

    Innan du binder dig, titta på den rapporterade storleken och typen. En "film" på 14 KB är en HTML-sida. En typ av text/html där du väntade dig video/mp4 betyder att du har fel länk.

  3. Välj kvaliteten du vill ha

    En ström erbjuder vanligtvis flera. Den högsta är inte alltid rätt svar på en telefon, där skillnaden är osynlig och lagringen inte är det.

  4. Låt sessionen följa med

    Skyddade länkar kontrollerar vem som frågar: kakorna från din inloggade session, sidan som hänvisade dig, ibland webbläsaridentiteten. En nedladdning startad utan dem får ett 403 trots att sidan spelade upp fint.

  5. Verifiera vad som landade

    Öppna det. En fil som spelar i två sekunder och stannar var trunkerad — vanligtvis en utgången länk — och är värd att starta om snarare än att behålla.

Vad en webbläsare i en app måste göra rätt

Utöver att hitta mediet är det här sakerna som avgör om nedladdningen faktiskt slutförs.

  • Bär sessionen genom till nedladdningen

    Kakor, referer och användaragent måste följa med i förfrågan. Utan dem löses en skyddad länk upp på sidan och misslyckas i nedladdaren.

  • Håll de inloggningsuppgifterna borta från lagring

    Sessionskakor är lika bra som ett lösenord under sessionens längd. De hör hemma i minnet under överföringens varaktighet och ingen annanstans — inte i en databas, inte i en logg.

  • Vägra lämna över länken till en annan app

    iOS öppnar gärna en tryckt länk i en annan app om den hävdar den domänen. En webbläsare avsedd att spara media måste avbryta och återutfärda navigeringen själv, annars försvinner sidan du ville ha in i någon annans app.

  • Trimma sidan innan den renderas

    En innehållsblockerare handlar inte bara om reklam här — färre spårare och overlays betyder färre falska kandidater i medielistan.

  • Hantera dokument lika väl som video

    PDF:er, ZIP-filer och Office-filer är den andra hälften av vad folk sparar från webben, och de bör hamna i samma bibliotek som allt annat.

Frågor folk ställer

Varför kan inte Safari göra det här på egen hand?

Safari laddar visst ner filer — det har den gjort sedan iOS 13. Vad den inte gör är att undersöka en sida efter media som strömmas snarare än länkas, eller bygga om en segmenterad ström till en fil. Det är en webbläsare, och det jobbet hör hemma i en nedladdningshanterare.

Vad är en blob-URL och varför kan jag inte ladda ner den?

Det är ett handtag till data sidan redan håller i minnet. Den har ingen existens utanför den fliken, så att klistra in den någonstans ger inget. Det underliggande mediet hämtades från någonstans riktigt, och den adressen — inte bloben — är den värd att hitta.

Sidan spelar upp fint men nedladdningen får ett 403. Varför?

Nedladdningsförfrågan anlände utan det sidan hade: din sessionskaka, den hänvisande sidan, ibland en matchande webbläsaridentitet. Servrar använder exakt den kombinationen för att skilja en tittare från en skrapare.

Kan allt sparas?

Nej, och det är avsiktligt. Innehåll skyddat med DRM är krypterat med nycklar utfärdade under en licens som förbjuder att behålla det. Vissa sajter signerar också varje segment individuellt med kortlivade token. Båda fungerar som avsett.

FoxDL

Webbläsaren inuti FoxDL

Det är en vanlig flikad webbläsare vars jobb är att få saker in i ditt bibliotek snarare än att vara din vardagswebbläsare.

  • Sex upptäcktskanaler, inklusive shadow DOM och registret över vad sidan faktiskt begärt, så en spelare byggd helt i JavaScript är fortfarande synlig.
  • Den riktiga typen sniffas från svaret snarare än gissas från filändelsen, och blob:-kandidater som inte kan hämtas filtreras bort i stället för att erbjudas och misslyckas.
  • Kakor, referer och användaragent bärs igenom till nedladdningen så en skyddad länk löses upp — och ingen av dem skrivs någonsin till disk.
  • En innehållsblockerare trimmar sidan innan den renderas.
  • PDF:er, ZIP-filer och dokument sparas till samma bibliotek som media, med ett tryck.
  • Flikar, bokmärken och en startsida med dina egna genvägar.

FoxDL tillhandahåller inget eget innehåll. Vad du sparar är vad du tog med, och du ansvarar för att ha rätt att behålla det.

Vanliga frågor

Alla frågor

Läs vidare

Vad en nedladdningshanterare gör som en webbläsare inte gör

Varför överföringar stannar när du byter app, vad återupptagning egentligen kräver, och hur strömmar blir filer.

Vad en medieapp på din telefon kan se, och vad den aldrig bör skicka

Vad en medieapp kan se, hur man läser en integritetsetikett, och varför ett lås inte är kryptering.

Var dina filer faktiskt bor på en iPhone, och vem som kan se dem

Sandlådan, var nedladdningar faktiskt hamnar, och varför att byta namn på en fil ställer till det för så många appar.

Ditt bibliotek, äntligen på ett ställe.

Gratis nedladdning. Inget konto, ingen registrering — hela funktionsuppsättningen finns i gratisversionen.

Ladda ner från App Store