
Een enorm JSON-bestand bekijken zonder je browser te laten crashen
Gepubliceerd op 23 jul 2026
Een API-dump van 50MB of een volledige database-export plakken in welke browsergebaseerde JSON-tool dan ook — deze incluis — maakt het tabblad traag of laat het compleet bevriezen. Dat is geen bug in een specifieke tool, het is een eigenschap van hoe browsers tekst en DOM renderen. Dit is wat er werkelijk gebeurt en hoe je eromheen werkt.
Waarom grote JSON-bestanden de browser bevriezen, en niet gewoon “langzaam laden”
Twee aparte kostenposten stapelen zich op:
- Parseerkosten.
JSON.parseop een correct gevormde string van 50MB duurt op een normale laptop ruwweg een halve seconde tot een paar seconden — merkbaar, maar niet het echte probleem. - Renderkosten. Dit is degene die het tabblad daadwerkelijk bevriest. Als een tool het geformatteerde resultaat als één gigantisch tekstblok rendert (of erger, als een inklapbare boom met een DOM-node per key), moet de browser potentieel miljoenen DOM-nodes indelen en tekenen. Dit maakt het tabblad onbruikbaar, niet het parsen.
De groottelimiet waar je tegenaan loopt komt dus vrijwel nooit uit de JSON-specificatie of de parser — hij komt doordat je een browser vraagt een enorme hoeveelheid tekst of geneste UI in één keer te tekenen.
De echte workflow voor werkelijk grote bestanden
Open het geheel nergens in een browser. Doe in plaats daarvan dit:
- Haal eerst alleen het deel eruit dat je nodig hebt. Debug je één kapot record in een dump van 200MB, dan heb je de andere 199MB niet voor je neus nodig. Commandline-tools doen dit zonder ooit het volledige bestand in het geheugen te laden zoals een browsertabblad dat doet:
# 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 - Formatteer alleen dat fragment in de browser. Een paar KB uitgeknipte JSON formatteert direct en is daadwerkelijk leesbaar — dit is dezelfde gewoonte van “formatteer alleen het fragment dat je interesseert” die het aanleren waard is voor elke grote log of dump, niet alleen voor deze specifieke fout.
- Moet je structuur inspecteren, geen waarden, draai dan eerst lokaal
jq 'keys'ofjq '. | length'om de vorm te begrijpen voordat je besluit wat je eruit haalt. Je hoeft geen 50.000 array-items te zien om te weten dat de array 50.000 items heeft.
Wanneer een browsertool prima volstaat
Voor het overgrote deel van het echte debugwerk — een API-response, een configbestand, een webhook-payload — heb je te maken met kilobytes tot een paar megabytes, geen honderden. In dat bereik is direct in een formatter plakken en meteen leesbare uitvoer met exacte foutlocaties krijgen sneller dan überhaupt naar de commandline grijpen. De grootte waarbij dit stukloopt ligt veel hoger dan de meeste mensen denken; het is specifiek “tientallen megabytes en meer” dat echte problemen geeft, niet “meer dan één pagina”.
Snelle referentie
| Bestandsgrootte | Wat te doen |
|---|---|
| Onder ~5MB | Direct in een browserformatter plakken — instant, prima |
| ~5–30MB | Nog werkbaar, maar reken op een korte hapering; formatteer alleen wat je moet lezen |
| 30MB+ | Haal eerst het relevante fragment eruit met jq/grep, formatteer alleen dat |
De tool heeft geen “large file mode” nodig om dit op te lossen — de oplossing is extraheren voordat je bekijkt, en dat is een workflowverandering, geen toolbeperking.