Formateur JSONL

À propos de GeekFormat

Collez ici du JSONL ou du NDJSON. Les lignes vides sont ignorées automatiquement et chaque ligne de données doit être un objet JSON complet.

Le résultat formaté s'affichera ici.

Chaque ligne non vide doit être un objet JSON complet.

Lignes totales: 1Lignes non vides: 0Lignes valides: 0Lignes invalides: 0

Collez du JSONL pour lancer immédiatement le formatage.

Une page légère de formatage JSONL dédiée aux journaux, archives de sessions et exports en flux. Collez à gauche les objets JSON séparés par des sauts de ligne, et apercevez immédiatement à droite le résultat formaté de chaque enregistrement, en voyant directement quelle ligne est défectueuse.

Recommandations connexes

Formatage JSON

Réparer JSON

Compression JSON

JSON Stringify

Validateur JSON Schema

Qu'est-ce que le formatage JSONL ?

JSONL (JSON Lines) est un format texte qui organise les enregistrements JSON par lignes. Sa caractéristique centrale n'est pas de « ressembler à du JSON », mais que « chaque enregistrement occupe sa propre ligne ». En ingénierie réelle, cela se traduit presque toujours par : chaque ligne non vide est un objet JSON complet, les objets étant séparés par des sauts de ligne au lieu d'être enveloppés dans un grand tableau `[{...},{...}]`.

Cette organisation convient particulièrement aux journaux, flux d'événements, archives de sessions, exports par lots et traitements en flux : le programme n'a pas besoin de charger tout le fichier en mémoire et peut consommer les enregistrements ligne par ligne. Si une ligne est défectueuse, on localise directement son numéro, au lieu de compter les accolades et chercher les virgules à l'aveugle dans un très long tableau JSON.

Le formatage JSONL n'est pas le formatage JSON ordinaire. Un formateur classique suppose que l'entrée est un document JSON complet unique ; un formateur JSONL doit au contraire analyser, valider et signaler les erreurs ligne par ligne, tout en préservant la sémantique des enregistrements séparés par des sauts. Pour les journaux et les fichiers d'export, cette différence est déterminante.

Cette page est conçue autour de cette sémantique réelle : à gauche, saisissez les enregistrements d'objets séparés par des lignes ; à droite, le résultat formaté s'affiche enregistrement par enregistrement, tandis que les lignes défectueuses, tronquées et non-objet sont signalées directement. Lorsque vous examinez un fichier `.jsonl`, vous voyez donc « quel enregistrement pose problème » plutôt qu'un `SyntaxError` générique.

Cas d'utilisation

Embellir enregistrement par enregistrement le JSONL exporté des journaux d'application avant de vérifier les champs un par un, plutôt que de fixer une longue suite d'objets compressés sur une seule ligne
Vérifier les fichiers d'archives de sessions où chaque ligne est un objet événement, et confirmer que chaque enregistrement est complet et lisible
Lorsqu'un pipeline de données, une plateforme de tracking ou un export bulk Elasticsearch échoue, identifier rapidement quelle ligne d'objet JSON est mal formée
Au débogage d'interfaces en flux, vérifier que le serveur produit bien en continu « un objet par ligne » au lieu de diffuser prématurément un objet à moitié formé
Coller le NDJSON copié depuis un terminal, un tableau de bord de supervision ou une plateforme de logs cloud : d'abord structurer, puis poursuivre l'investigation
Vérifier si une ligne des résultats d'objets ligne par ligne générés par l'IA contient par erreur un tableau, une chaîne ou un JSON incomplet
Avant une importation dans ClickHouse, BigQuery, Kafka Connect ou tout flux dépendant d'enregistrements ligne par ligne, relire manuellement le contenu JSONL
Lors de l'audit de journaux d'audit, d'événements de risque ou de flux d'événements de tracking, vérifier enregistrement par enregistrement la stabilité et la cohérence de la structure des objets
Lorsqu'un fichier JSONL est tronqué ou téléchargé de façon incomplète, voir immédiatement quel dernier objet n'est pas refermé
Formater d'abord le JSON ligne par ligne exporté par les outils internes, puis l'envoyer à un collègue pour revue de code ou contrôle de données
Avant d'écrire un script qui analyse du JSONL, confirmer manuellement les niveaux de champs, les objets imbriqués et l'emplacement des tableaux pour réduire le temps de débogage du script
Sur des exports historiques mêlant lignes vides et lignes défectueuses, filtrer d'abord les problèmes de structure avant de décider d'une conversion en CSV ou d'un import en base

Comment utiliser

Collez le contenu JSONL ou NDJSON dans la zone de saisie, en garantissant que chaque ligne non vide est un objet JSON indépendant
La droite formate immédiatement ligne par ligne et signale, sur les lignes défectueuses, le numéro de ligne, le message d'erreur et l'enregistrement d'origine
Corrigez les lignes indiquées jusqu'à ce que le nombre de lignes invalides tombe à zéro
Une fois tout valide, copiez le résultat formaté complet, ou envoyez les données aux scripts, importeurs et processus d'analyse en aval

Fonctionnalités

Analyse JSONL / NDJSON ligne par ligne, sans avoir à emballer d'abord les données dans un tableau JSON complet comme `[{...},{...}]`
Validation selon la sémantique réelle « chaque ligne non vide est un objet JSON », adaptée aux journaux, flux d'événements et archives de sessions
Mise en page en deux colonnes : saisie `textarea` à gauche, résultat formaté instantané à droite, idéale pour corriger au fil de l'eau
Les lignes défectueuses affichent directement le numéro de ligne, l'erreur d'analyse et le contenu d'origine, pour réparer vite les enregistrements tronqués, accolades manquantes et erreurs de concaténation
La copie n'est autorisée que lorsque toutes les lignes non vides sont valides, afin de ne pas transmettre aux processus en aval des données partiellement réussies et partiellement corrompues
Statistiques intégrées : lignes totales, lignes non vides, lignes valides et lignes invalides, pour juger d'un coup d'œil le nombre d'enregistrements défectueux dans un gros fichier
Des données d'exemple sont fournies pour tester le formatage JSONL dès la première ouverture
Tout le traitement s'effectue localement dans le navigateur ; journaux, événements de session et exports d'API ne sont jamais envoyés

Formateur JSONL vs formateur JSON vs réparation JSON

Ces outils sont souvent utilisés à la suite, mais ils ne résolvent pas les mêmes problèmes. Choisir la bonne entrée fait gagner beaucoup de temps.

Outil	Entrée la plus adaptée	Capacité clé	Cas d'usage
Formateur JSONL	Un objet JSON par ligne	Valider et embellir enregistrement par enregistrement	Journaux, NDJSON, archives de sessions, exports en flux
Formateur JSON	Un objet ou tableau JSON complet	Embellir tout le document JSON	Réponses d'API, fichiers de configuration, payloads ponctuels
Réparation JSON	Texte JSON avec erreurs de syntaxe ou non standard	Réparer d'abord la syntaxe puis passer aux outils suivants	Virgules finales, commentaires, problèmes de guillemets, JSON tronqué

Best Practices

Au débogage, gardez la forme JSONL d'origine plutôt que de l'emballer manuellement en tableau pour la comprendre

Si le système en aval attend du JSONL, faites vos vérifications autant que possible sous la forme d'origine « un enregistrement par ligne ». L'emballer en tableau permet de la passer à un formateur ordinaire, mais fait perdre la sémantique des numéros de ligne d'origine et rend plus difficile le repérage de la vraie ligne fautive.

Sur les gros fichiers, regardez d'abord les dernières lignes

Beaucoup de fichiers JSONL n'ont pas une erreur de structure au milieu : ce sont les dernières lignes qui sont tronquées par une coupure de flux, un échec de téléchargement ou une écriture inachevée. Examiner d'abord les derniers enregistrements est souvent plus rapide que de parcourir tout le fichier depuis le début.

Si l'entrée contient des guillemets simples, des commentaires ou un style JSON5, passez d'abord par la réparation JSON

La page JSONL met l'accent sur la validation d'objets ligne par ligne ; si les données sources ne sont pas du JSON standard dès le départ, réparer avant de formater est généralement plus efficace que de corriger à la main chaque ligne d'un long fichier.

Avant une réimportation, veillez à conserver la semántique de transport « un objet par ligne »

Le bloc multiligne embelli à droite est surtout destiné à la lecture humaine, mais si vous devez réécrire les données dans un système de journaux, une file de messages ou un importateur, conservez la structure source un objet par ligne au lieu de prendre l'aperçu comme format de transport final.

Faites des numéros de ligne votre indice principal, plutôt que de relire tout le fichier à l'œil

En vrai débogage, le plus rapide est généralement de verrouiller d'abord le numéro de ligne fautif, puis de comparer cet enregistrement avec les enregistrements valides voisins. On voit plus vite s'il manque une accolade ou un guillemet, si un champ est tronqué ou si un objet contient un mauvais type.

FAQ

Quelle différence entre JSON et JSONL ?

Le JSON ordinaire est généralement un objet ou un tableau entier, à analyser comme un document complet d'un seul tenant ; le JSONL (JSON Lines, aussi appelé NDJSON) stocke quant à lui un enregistrement indépendant par ligne, et dans la pratique d'ingénierie c'est le plus souvent « un objet JSON par ligne ». Il convient mieux aux journaux, flux d'événements, traitements en flux et imports par lots, car on peut lire, écrire et localiser les erreurs ligne par ligne.

Pourquoi cette page insiste-t-elle sur « un objet JSON par ligne » ?

Parce que la plupart des fichiers JSONL réels sont organisés ainsi, en particulier les journaux, archives de sessions, flux d'événements et fichiers d'export. Vos échantillons d'archives suivent aussi cette forme typique : chaque ligne est un objet séparé par un saut de ligne. La page valide selon cette sémantique, qui correspond bien mieux au débogage réel qu'une acceptation large de n'importe quelle valeur JSON.

En quoi JSONL diffère-t-il d'un tableau JSON comme `[{...},{...}]` ?

Un tableau JSON est un document JSON complet qu'il faut lire entièrement avant de l'analyser ; le JSONL découpe chaque objet en enregistrements de ligne indépendants, peut être lu en flux et permet de localiser directement la ligne fautive quand un enregistrement échoue. Pour les gros journaux et les flux d'événements, JSONL est donc mieux adapté qu'un tableau global.

Pourquoi les lignes vides sont-elles ignorées ?

Les lignes vides proviennent généralement du copier-coller, de la rotation des journaux ou d'une édition manuelle, et ne représentent pas de véritables enregistrements. Les ignorer réduit le bruit tout en continuant à vérifier strictement toutes les lignes qui contiennent des données.

Que se passe-t-il si une ligne est un tableau, une chaîne ou `null` ?

Cette page la considérera comme une ligne invalide, car le format visé est « chaque ligne non vide est un objet JSON ». Si vos données doivent réellement stocker ligne par ligne des tableaux ou des valeurs brutes, ce n'est pas le scénario typique de journal JSONL pour lequel cette page est optimisée.

Pourquoi ne pas copier directement tout le résultat quand il y a une ligne défectueuse ?

C'est une interaction volontairement conservatrice. La copie n'est autorisée que lorsque toutes les lignes non vides sont valides, afin de ne pas transmettre un résultat partiellement réussi et partiellement corrompu aux importeurs, scripts ou collègues en aval, et éviter ainsi une seconde passe de débogage.

Peut-il m'aider à détecter des fichiers journaux tronqués ?

Oui. Beaucoup de problèmes JSONL surviennent sur les dernières lignes : par exemple un objet auquel il manque `}`, une chaîne sans guillemet de fermeture ou un flux réseau interrompu en cours de route. La page expose directement la ligne fautive, particulièrement utile pour les téléchargements incomplets et les coupures de sortie en flux.

JSONL et NDJSON, est-ce la même chose ?

Dans la grande majorité des contextes d'ingénierie, on peut les considérer comme synonymes. Tous deux désignent des enregistrements JSON séparés par des sauts de ligne ; seule l'habitude de nommage diffère.

Le formatage JSONL envoie-t-il mes données ?

Non. Toute l'analyse, la validation et le formatage s'exécutent uniquement localement dans le navigateur ; journaux, réponses d'API, archives de sessions et exports de données ne sont jamais envoyés à un serveur.

Quand faut-il utiliser le formateur JSON ordinaire plutôt que le formateur JSONL ?

Si votre entrée est elle-même un objet JSON complet ou un tableau, comme le corps d'une réponse d'API, un fichier de configuration ou un paquet de données type `[{...},{...}]`, c'est la page de formatage JSON ordinaire qu'il faut utiliser ; ce n'est que lorsque l'entrée est constituée d'enregistrements d'objets séparés par des sauts de ligne que cette page JSONL est la plus adaptée.

Glossaire

JSONL: Format texte dont les enregistrements JSON sont séparés par des lignes. L'écriture d'ingénierie la plus courante : chaque ligne non vide est un objet JSON complet.
JSON Lines: La forme complète et une autre appellation courante de JSONL, généralement considéré comme synonyme.
NDJSON: Newline Delimited JSON, soit « JSON délimité par des sauts de ligne ». Quasi-équivalent à JSONL dans la plupart des scénarios de journaux et de pipelines de données.
Enregistrement ligne par ligne: Disposition des données où chaque ligne représente un enregistrement complet, adaptée à l'écriture et la lecture en flux ainsi qu'à la localisation des erreurs par ligne.
Pretty Print / mise en forme lisible: Réorganiser un JSON compact d'une ligne en une structure lisible avec indentation et sauts de ligne, pour faciliter l'inspection manuelle des niveaux de champs.
Ligne défectueuse: Une ligne qui n'est pas du JSON valide, ou qui bien qu'analysable ne correspond pas à la structure attendue (par exemple n'est pas un objet) et ne peut donc pas constituer un enregistrement JSONL valide.
Flux tronqué: Un journal ou un export interrompu en cours de transmission, de vidage ou d'enregistrement, si bien que le dernier enregistrement n'est pas complètement refermé.
Tableau JSON: En JSON standard, une collection entière entourée par `[` et `]`, par exemple `[{...},{...}]`. Contrairement au JSONL, il doit être analysé comme un document unique.

Authoritative References

jsonlines.orgPrésentation officielle de JSON Lines
IETFNorme JSON officielle RFC 8259