Webbläsarens minnesgränser vid filbehandling

Min fil är bara 15 MB. Varför fick fliken slut på minne?

4 min läsning · granskad 17 augusti 2026

Filen på disken är den komprimerade versionen

Hela missförståndet ryms i en mening: siffran du ser i filhanteraren är storleken på komprimerad data, och ingenting kan bearbetas så länge det är komprimerat. För att skala om, komprimera om, konvertera eller analysera en bild måste den först avkodas till råa pixlar, och råa pixlar är enorma.

Räknestycket är enkelt. En pixel i minnet är normalt fyra byte — rött, grönt, blått och alfa. Ett fotografi på 4000 × 3000 är tolv miljoner pixlar, så den avkodade bitmappen blir omkring 48 MB. JPEG-filen den kom från kanske var 4 MB. Filen växte tolv gånger innan något arbete alls hade börjat.

Avkodad storlek för en bild, vid fyra byte per pixel
Mått	Pixlar	Avkodad bitmapp
1920 × 1080	2,1 miljoner	cirka 8 MB
4000 × 3000	12 miljoner	cirka 48 MB
6000 × 4000	24 miljoner	cirka 96 MB
10000 × 10000	100 miljoner	cirka 400 MB

Och en kopia räcker aldrig

En realistisk kedja håller flera kopior samtidigt: de komprimerade indatabytena, den avkodade källbitmappen, en utdatabitmapp i de nya måtten, kodarens interna buffertar och det komprimerade resultatet. Ett verktyg som dessutom visar en förhandsgranskning håller ytterligare en. För fotografiet på 4000 × 3000 ovan är en topp på två till tre hundra megabyte i arbetsminne helt normal — för en fil som såg ut att vara 4 MB.

PDF-rastrering beter sig likadant, sida för sida: en A4-sida renderad i 300 DPI är ungefär 2480 × 3508 pixlar, omkring 35 MB avkodad, och ett verktyg som renderar flera sidor samtidigt multiplicerar det. Video är ännu värre, eftersom en avkodare behöver ha flera referensbilder i minnet samtidigt.

Var de verkliga taken ligger

En fliks minnesbudget bestäms av webbläsaren, inte av webbplatsen, och den är mindre än datorns installerade minne. Den krymper dessutom när andra flikar arbetar.
WebAssembly-moduler byggda för den vanliga 32-bitars minnesmodellen kan adressera högst fyra gibibyte, och webbläsare tillåter ofta betydligt mindre än så per instans.
Enskilda buffertar har en egen maxlängd, som ligger klart under det totala minne en sida får använda.
Mobila operativsystem avslutar en flik som växer sig för stor, utan förvarning och utan något fel som sidan kan fånga.
Grafikminnet är en separat och mindre pool. En Canvas som är större än plattformens maxmått misslyckas helt enkelt, hur mycket systemminne som än är ledigt.

Inget av det här publiceras som en enda siffra att slå upp, eftersom gränserna beror på webbläsaren, versionen, enheten och vad som körs i övrigt. Det är den verkliga svårigheten: ett verktyg kan inte fråga hur mycket minne det får använda.

Varför telefoner är det snävaste fallet

Telefoner har mindre fysiskt minne, ingen växlingsfil i skrivbordsdatorernas mening och ett operativsystem som är aggressivt med att ta tillbaka minne från bakgrundsprocesser. En webbläsarflik är en bakgrundsprocess i samma stund som du svarar på ett meddelande. Mobila webbläsare håller därför snävare budgetar och slänger en flik snabbare, och för dig ser det oftast ut som att sidan laddas om och tappar ditt arbete snarare än som ett fel.

Den praktiska följden är att ett jobb som går igenom på en laptop kan vara omöjligt på en telefon med samma fil. Det är inte ett fel i verktyget. Det är en hårdvarugräns, och det ärliga är att säga det innan man börjar i stället för att krascha halvvägs.

Så beter sig ett omsorgsfullt verktyg

Det uppskattar minnesbehovet utifrån de avkodade måtten innan det allokerar något, och avvisar ett jobb som uppenbart inte får plats.
Det bearbetar en fil i taget på en begränsad enhet i stället för att köra en hel batch parallellt.
Det överför buffertar mellan sidan och dess workers i stället för att kopiera dem, så att en stor fil inte finns i två exemplar.
Det frigör varje resultat så snart det är skrivet, och återkallar de tillfälliga URL:er som annars skulle hålla data vid liv.
Det strömmar sida för sida eller bildruta för bildruta där formatet tillåter det, i stället för att läsa in ett helt dokument i minnet.
Det sätter ett tak för hur många pixlar det accepterar, vilket också är det som hindrar en liten fil som expanderar till en enorm Canvas från att fälla fliken.

Vad du kan göra när ett jobb misslyckas

Stäng andra flikar. De konkurrerar om samma budget, och webbläsare fördelar den inte rättvist.
Bearbeta färre filer åt gången. En kö på en enda fil är långsammare och betydligt mer sannolik att gå i mål.
Minska måtten först. Att halvera längsta sidan lämnar en fjärdedel av minnesbehovet kvar, och det är ofta ändå det du ville.
Dela upp en stor PDF och bearbeta delarna.
Gå över till en stationär dator för de största jobben. Det är inte ett misslyckande för lokal bearbetning; det är rätt användning av hårdvaran du har.
Starta om webbläsaren om en flik har stått öppen i dagar. Långlivade flikar samlar på sig minne som en omladdning frigör.

Gränsen för varje uppskattning

Webbläsare avslöjar bara en grov ledtråd om tillgängligt minne, och vissa avslöjar ingenting alls. Varje siffra ett lokalt verktyg visar dig är därför en uppskattning byggd på filens egna mått och en försiktig modell av kedjan, inte en avläsning från operativsystemet. Den är användbar för att avgöra om ett jobb är värt att försöka. Den är inget löfte om att jobbet går i mål, eftersom den avgörande faktorn — vad resten av enheten gör de närmaste trettio sekunderna — inte är något en webbsida kan se.

Verktyg för det här

Källor

Fler guider

Alla FileSlimmer-guider