JSONL-formatter

Over GeekFormat

Plak hier JSONL of NDJSON. Lege regels worden automatisch overgeslagen en elke dataregel moet een compleet JSON-object zijn.

Het geformatteerde resultaat verschijnt hier.

Elke niet-lege regel hoort een compleet JSON-object te zijn.

Totaal regels: 1Niet-lege regels: 0Geldige regels: 0Ongeldige regels: 0

Plak JSONL om direct te beginnen met formatteren.

Een lichte JSONL-formatteringspagina voor logs, sessiearchieven en streaming-exports. Plak links de door regeleinden gescheiden JSON-objecten; rechts verschijnt direct het geformatteerde resultaat per record en zie je meteen welke regel kapot is.

Gerelateerde aanbevelingen

JSON Formatter

JSON repareren

JSON Compress

JSON Stringify

JSON Schema Validator

Wat is JSONL-formattering?

JSONL (JSON Lines) is een tekstformaat dat JSON-records per regel organiseert. Het kernkenmerk is niet «lijkt op JSON», maar «elk record staat op een eigen regel». In de echte engineering betekent dat bijna altijd dat elke niet-lege regel een compleet JSON-object is, waarbij objecten door regeleinden worden gescheiden in plaats van extra in één grote array `[{...},{...}]` te worden verpakt.

Die organisatie past bijzonder goed bij logs, gebeurtenisstromen, sessiearchieven, bulkexports en streaming: een programma hoeft niet het hele bestand in het geheugen te laden, maar kan records regel voor regel verwerken. Is een regel kapot, dan wijs je direct het regelnummer aan in plaats van blindelings haakjes te tellen en komma's te zoeken in een ellenlange JSON-array.

JSONL-formattering is niet hetzelfde als gewone JSON-formattering. Een gewone formatter gaat ervan uit dat de invoer één compleet JSON-document is; een JSONL-formatter moet per regel parseren, per regel valideren en per regel fouten melden, met behoud van de regelgescheiden recordsemantiek. Voor logs en exportbestanden is dat verschil cruciaal.

Deze pagina is rond die echte semantiek ontworpen: links voer je regelgescheiden objectrecords in, rechts toont het geformatteerde resultaat per record, terwijl kapotte, afgekapte en niet-objectregels direct worden aangewezen. Zo zie je bij het onderzoeken van een `.jsonl`-bestand «welk record een probleem heeft» in plaats van een algemene `SyntaxError` te krijgen.

Toepassingsgevallen

Als JSONL geëxporteerde applicatielogs per record verfraaien voordat je veld voor veld op zoek gaat, in plaats van te staren naar een lange, tot één regel samengeperste reeks objecten
Sessiearchiefbestanden controleren waarin elke regel een gebeurtenisobject is, en bevestigen dat elk record compleet en leesbaar is
Wanneer een bulkexport van een datapijplijn, trackingplatform of Elasticsearch faalt, snel vaststellen welke regel van het JSON-object fout is geschreven
Bij het debuggen van streaming-interfaces controleren of de server echt continu «één object per regel» levert in plaats van voortijdig een half object uit te sturen
NDJSON die je uit de terminal, monitoringspanelen of cloud-logplatforms kopieert hier plakken: eerst structureren en dan verder onderzoeken
Controleren of in door AI gegenereerde regel-voor-regel-objectresultaten ergens een array, string of onvolledige JSON is binnengeslopen
Vóór import in processen die afhankelijk zijn van regelrecords, zoals ClickHouse, BigQuery of Kafka Connect, de JSONL-inhoud eerst handmatig nalopen
Bij de beoordeling van auditlogs, risicogebeurtenissen of tracking-gebeurtenisstromen per record nagaan of de objectstructuur stabiel en consistent blijft
Wanneer een JSONL-bestand is afgekapt of onvolledig gedownload, direct zien welk laatste object niet is gesloten
Door interne tools geëxporteerde regelgescheiden JSON eerst formatteren en dan naar een collega sturen voor code review of gegevenscontrole
Vóór het schrijven van een script dat JSONL parseert, eerst handmatig veldniveaus, geneste objecten en arrayposities vaststellen om de debugtijd van het script te verkorten
Bij historische exports met lege en kapotte regels door elkaar eerst de structuurproblemen eruit filteren voordat je beslist of conversie naar CSV of database-import volgt

Hoe te gebruiken

Plak de JSONL- of NDJSON-inhoud in het invoerveld en zorg dat elke niet-lege regel een zelfstandig JSON-object is
Rechts wordt direct per regel geformatteerd en bij kapotte regels verschijnen het regelnummer, de foutmelding en het originele record
Herstel de genoemde regels aan de hand van de meldingen totdat het aantal ongeldige regels op nul staat
Pas als alles geldig is, kopieer je het complete geformatteerde resultaat of stuur je de gegevens door naar volgende scripts, importeurs en analyseprocessen

Functies

Parseert JSONL / NDJSON regel voor regel, zonder dat je de gegevens eerst handmatig in een complete JSON-array zoals `[{...},{...}]` hoeft te verpakken
Valideert volgens de echte bestandssemantiek «elke niet-lege regel is een JSON-object», passend bij gangbare gegevensvormen zoals logs, gebeurtenisstromen en sessiearchieven
Gesplitste lay-out: links een `textarea`-invoer, rechts direct het geformatteerde resultaat, ideaal om al kijkend te herstellen
Kapotte regels tonen direct het regelnummer, de parserfout en de originele inhoud, zodat afgekapte records, ontbrekende haakjes en samenvoegfouten snel zijn te herstellen
Kopiëren wordt alleen vrijgegeven als alle niet-lege regels geldig zijn, zodat geen deels goede, deels beschadigde gegevens naar volgende processen lekken
Ingebouwde tellingen voor totaalregels, niet-lege, geldige en ongeldige regels, om in een groot bestand snel te zien hoeveel records beschadigd zijn
Inclusief voorbeeldgegevens, zodat je de JSONL-formattering direct bij het eerste openen kunt uitproberen
Alle verwerking gebeurt lokaal in de browser; logs, sessiegebeurtenissen en API-exports worden niet geüpload

JSONL-formatter vs JSON-formatter vs JSON-reparatie

Deze tools worden vaak na elkaar gebruikt, maar lossen verschillende problemen op. De juiste ingang kiezen scheelt veel tijd.

Tool	Meest geschikte invoer	Kernvermogen	Gebruiksscenario
JSONL-formatter	Eén JSON-object per regel	Per record valideren en verfraaien	Logs, NDJSON, sessiearchieven, streaming-exports
JSON-formatter	Eén compleet JSON-object of -array	Het hele JSON-document verfraaien	API-antwoorden, configuratiebestanden, eenmalige payloads
JSON-reparatie	JSON-tekst met syntaxisfouten of niet-standaard vorm	Eerst de syntax herstellen, dan verder	Volgkomma's, commentaren, aanhalingstekens, afgekapte JSON

Best Practices

Houd bij debuggen de originele JSONL-vorm in plaats van hem alleen om te begrijpen handmatig in een array te verpakken

Als het volgende systeem JSONL verwacht, onderzoek dan zoveel mogelijk in de originele «één record per regel»-vorm. Alles in een array verpakken lukt wel in een gewone formatter, maar je verliest de semantiek van de originele regelnummers en kunt de echte kapotte regel moeilijker aanwijzen.

Kijk bij grote bestanden eerst naar de laatste regels

Veel JSONL-bestanden hebben geen structuurfout in het midden; de laatste regels zijn afgekapt door een onderbroken stroom, mislukte download of onvoltooide schrijfactie. Eerst de laatste records bekijken is meestal sneller dan het hele bestand van voren af aan doorlopen.

Bevat de invoer enkele aanhalingstekens, commentaren of JSON5-stijl, ga dan eerst langs JSON-reparatie

De JSONL-pagina richt zich op objectvalidatie per regel; als de brongegevens van huis uit geen standaard-JSON zijn, is eerst repareren en dan formatteren meestal efficiënter dan elke regel van een lang bestand handmatig aanpassen.

Houd bij herimport beslist de transportsemantiek «één object per regel» in stand

Het meerregelige verfraaide blok rechts is vooral bedoeld voor mensen, maar als je de gegevens terugschrijft naar een logsysteem, berichtenwachtrij of importeur, behoud dan de bronstructuur van één object per regel in plaats van de previewvorm als eindformaat te gebruiken.

Gebruik regelnummers als voornaamste aanwijzing in plaats van het hele bestand met het oog door te lezen

Bij echt debuggen is de snelste weg meestal eerst het kapotte regelnummer vastzetten en dat record met een naburig geldig record vergelijken. Zo zie je sneller of er een haakje of aanhalingsteken ontbreekt, een veld is afgekapt of een object een verkeerd type bevat.

Veelgestelde vragen

Wat is het verschil tussen JSON en JSONL?

Gewone JSON is meestal één compleet object of één array die als één volledig document wordt geparseerd; JSONL (JSON Lines, ook vaak NDJSON genoemd) bevat daarentegen één onafhankelijk record per regel, en in de praktijk is dat meestal «één JSON-object per regel». Het past beter bij logs, gebeurtenisstromen, streaming en bulkimport, omdat je regel voor regel kunt lezen, schrijven en fouten kunt lokaliseren.

Waarom benadrukt deze pagina «één JSON-object per regel»?

Omdat de meeste echte JSONL-bestanden nu eenmaal zo zijn opgebouwd, vooral logs, sessiearchieven, gebeurtenisstromen en exports. Jouw archiefvoorbeelden volgen ook die typische vorm: elke regel is een door een regeleinde gescheiden object. De pagina valideert volgens deze semantiek, die veel beter past bij echt debuggen dan het ruim accepteren van willekeurige JSON-waarden.

Waarin verschilt JSONL van een JSON-array zoals `[{...},{...}]`?

Een JSON-array is één compleet JSON-document dat eerst helemaal moet worden gelezen voordat je het parseert; JSONL splitst elk object in zelfstandige regelrecords, kan streaming worden gelezen en maakt het eenvoudiger om bij een fout direct de bijbehorende regel te vinden. Voor grote logbestanden en gebeurtenisstromen is JSONL daardoor geschikter dan één grote array.

Waarom worden lege regels genegeerd?

Lege regels zijn meestal afkomstig van kopiëren en plakken, logrotatie of handmatige bewerking en vertegenwoordigen geen echte gegevensrecords. Ze negeren vermindert ruis, terwijl alle regels met inhoud wel streng worden gecontroleerd.

Wat gebeurt er als een regel een array, een string of `null` is?

Deze pagina beschouwt die als ongeldige regel, want het beoogde formaat is «elke niet-lege regel is een JSON-object». Als jouw gegevens echt arrays of ruwe waarden per regel moeten opslaan, is dit niet het typische JSONL-logscenario waarop deze pagina is geoptimaliseerd.

Waarom kan ik bij één kapotte regel niet direct het hele resultaat kopiëren?

Dat is een bewust conservatieve interactie. Kopiëren mag alleen als alle niet-lege regels geldig zijn, om te voorkomen dat een deels geslaagd, deels beschadigd resultaat wordt doorgestuurd naar importeurs, scripts of collega's; dat bespaart een tweede zoekronde.

Kan het me helpen afgekapte logbestanden te ontdekken?

Ja. Veel JSONL-problemen zitten in de laatste regels: een object mist bijvoorbeeld `}`, een string mist het afsluitende aanhalingsteken of een netwerkstroom breekt halverwege af. De pagina legt de bijbehorende kapotte regel direct bloot, vooral handig bij onvolledige downloads en onderbroken streaming-uitvoer.

Zijn JSONL en NDJSON hetzelfde?

In vrijwel alle engineeringcontexten zijn ze als synoniemen te gebruiken. Beide duiden op door regeleinden gescheiden JSON-records; alleen de naamgeving verschilt.

Worden mijn gegevens bij het formatteren van JSONL geüpload?

Nee. Alle parsing, validatie en formattering vindt uitsluitend lokaal in de browser plaats; logs, API-antwoorden, sessiearchieven en gegevensexports gaan niet naar een server.

Wanneer gebruik ik de gewone JSON-formatter in plaats van de JSONL-formatter?

Als de invoer zelf een compleet JSON-object of een array is, zoals de body van een API-antwoord, een configuratiebestand of een gegevenspakket als `[{...},{...}]`, hoor je op de gewone JSON-formatteringspagina te zijn; alleen wanneer de invoer bestaat uit door regeleinden gescheiden objectrecords past deze JSONL-pagina beter.

Woordenlijst

JSONL: Een tekstformaat met door regels gescheiden JSON-records. De meest gebruikelijke engineeringvorm: elke niet-lege regel is een compleet JSON-object.
JSON Lines: De volledige naam en een andere gangbare benaming voor JSONL, meestal als synoniem beschouwd.
NDJSON: Newline Delimited JSON, letterlijk «door regeleinden gescheiden JSON». In de meeste log- en datapijplijnscenario's nagenoeg gelijk aan JSONL.
Regelrecord: Een gegevensindeling waarbij elke regel één compleet record vertegenwoordigt, geschikt voor streaming schrijven en lezen en het per regel lokaliseren van fouten.
Pretty Print / leesbare formattering: Samengeperste JSON van één regel herschikken tot een leesbare structuur met inspringing en regeleinden, zodat veldniveaus handmatig zijn te bekijken.
Kapotte regel: Een regel die geen geldige JSON is, of die wel parseerbaar is maar niet aan de verwachte structuur voldoet (bijvoorbeeld geen object is) en daardoor geen geldig JSONL-record vormt.
Afgekapte stroom: Een log of export die tijdens verzending, flush of opslaan halverwege is afgebroken, waardoor het laatste record niet volledig is gesloten.
JSON-array: In standaard-JSON een complete verzameling tussen `[` en `]`, bijvoorbeeld `[{...},{...}]`. Anders dan JSONL moet deze als één geheel document worden geparseerd.

Authoritative References

jsonlines.orgOfficiële toelichting JSON Lines
IETFOfficiële JSON-specificatie RFC 8259