CodeKitHub
Så visar du en enorm JSON-fil utan att krascha webbläsaren

Så visar du en enorm JSON-fil utan att krascha webbläsaren

Publicerad 23 juli 2026

Att klistra in en 50MB stor API-dump eller en fullständig databasexport i vilket webbläsarbaserat JSON-verktyg som helst — det här inkluderat — gör att fliken saktar ner eller fryser helt. Det är inte en bugg i ett specifikt verktyg, det är en egenskap hos hur webbläsare renderar text och DOM. Här är vad som faktiskt händer och hur du kan kringgå det.

Varför stora JSON-filer fryser webbläsaren, inte bara “laddar långsamt”

Två separata kostnader staplas på varandra:

  1. Tolkningskostnad (parsing). JSON.parse på en välformad 50MB-sträng tar ungefär en halv sekund till ett par sekunder på en vanlig laptop — märkbart, men inte det egentliga problemet.
  2. Renderingskostnad. Det är den som faktiskt fryser fliken. Om ett verktyg renderar det formaterade resultatet som ett gigantiskt textblock (eller värre, ett hopfällbart träd med en DOM-nod per nyckel), måste webbläsaren layouta och rita potentiellt miljontals DOM-noder. Det är vad som gör fliken oresponsiv, inte tolkningen.

Så gränsen du stöter på kommer nästan aldrig från JSON-specifikationen eller tolkaren — den kommer från att be en webbläsare att rita en enorm mängd text eller nästlat gränssnitt på en gång.

Det faktiska arbetsflödet för genuint stora filer

Öppna inte hela filen någonstans i en webbläsare. Gör istället så här:

  1. Extrahera bara den del du behöver först. Om du felsöker en trasig post inuti en 200MB stor dump behöver du inte de andra 199MB framför dig. Kommandoradsverktyg hanterar detta utan att någonsin ladda hela filen i minnet på det sätt en webbläsarflik gör:
    # pull out one top-level key from a huge file, streaming
    jq '.results[42]' huge-file.json > fragment.json
    
    # or just grep for context around a known string first
    grep -n '"user_id": 88214' huge-file.json
  2. Formatera bara det fragmentet i webbläsaren. Några KB extraherad JSON formateras direkt och är faktiskt läsbart — det här är samma “formatera bara det fragment du bryr dig om”-vana som är värd att bygga upp för alla stora loggar eller dumpar, inte bara det här specifika felet.
  3. Om du måste inspektera struktur, inte värden, kör jq 'keys' eller jq '. | length' lokalt först för att förstå formen innan du bestämmer vad du ska extrahera. Du behöver inte se 50 000 array-poster för att veta att arrayen har 50 000 poster.

När ett webbläsarverktyg faktiskt fungerar bra

För de allra flesta faktiska felsökningsfall — ett API-svar, en konfigurationsfil, en webhook-nyttolast — handlar det om kilobyte till några megabyte, inte hundratals. I det intervallet är det snabbare att klistra in direkt i en formaterare och få omedelbar, läsbar output med exakta felplatser än att över huvud taget gå till kommandoraden. Storleken där detta går sönder är mycket högre än de flesta tror; det är specifikt “tiotals megabyte och uppåt” som orsakar riktiga problem, inte “mer än en sida.”

Snabbreferens

Filstorlek Vad du ska göra
Under ~5MB Klistra in direkt i en webbläsarformaterare — omedelbart, inga problem
~5–30MB Fortfarande hanterbart, men förvänta dig en kort paus; formatera bara det du behöver läsa
30MB+ Extrahera det relevanta fragmentet med jq/grep först, formatera bara det

Verktyget behöver inte ett “stor fil-läge” för att lösa detta — lösningen är att extrahera innan du visar, vilket är en arbetsflödesförändring, inte en verktygsbegränsning.

← Tillbaka till bloggen