JSONLフォーマッター

ここに JSONL または NDJSON を貼り付けてください。空行は自動的に無視され、各データ行は完全な JSON オブジェクトである必要があります。

整形結果がここに表示されます。

空行以外の各行は、完全な JSON オブジェクトにしてください。

合計行数: 1空行以外の行: 0有効な行: 0不正な行: 0

JSONL を貼り付けると、すぐに整形が始まります。

ログ、セッションアーカイブ、ストリーム出力に向けた軽量なJSONL整形ページです。左側に改行で区切られたJSONオブジェクトを貼り付けると、右側に各レコードの整形結果がすぐに表示され、どの行が壊れているかが一目で分かります。

JSONL整形とは何ですか？

JSONL（JSON Lines）は、JSONレコードを行単位で並べるテキスト形式です。核心は「JSONに見えること」ではなく「各レコードが1行を占有すること」です。実務ではこれはほぼ必ず「空でない各行が完全なJSONオブジェクト」という形になり、オブジェクト同士は改行で区切られます。外側をさらに `[{...},{...}]` の大きな配列で包むわけではありません。

この構成はログ、イベントストリーム、セッションアーカイブ、一括エクスポート、ストリーム処理に特に適しています。ファイル全体をメモリに読み込まなくても、行を読むだけで1件ずつ処理できるからです。ある行が壊れていても、その行番号へ直接たどり着けるため、非常に長いJSON配列の中で闇雲に括弧を数えたりカンマを探したりする必要がありません。

JSONL整形は通常のJSON整形とは別物です。通常のフォーマッターは入力が完全な1つのJSONドキュメントであると前提しますが、JSONLフォーマッターは行ごとに解析し、行ごとに検証し、行ごとにエラーを出し、改行区切りのレコードという意味論を保つ必要があります。ログやエクスポートファイルにとって、この違いは非常に重要です。

このページはその実際の意味論を中心に設計されています。左側に改行区切りのオブジェクトレコードを入力すると、右側にレコードごとの整形結果が並び、壊れた行・途中で切れた行・オブジェクトでない行がその場で指摘されます。`.jsonl` ファイルを調べるとき、漠然とした `SyntaxError` ではなく「どのレコードに問題があるか」が見えるようになります。

ユースケース

アプリのログから書き出したJSONLを1件ずつ整形してからフィールドを追い込む。1行に押しつぶされた長いオブジェクト列とにらめっこする必要はありません
1行が1つのイベントオブジェクトになっているセッションアーカイブファイルを点検し、すべてのレコードが完全で読めるか確認する
データパイプライン、計測プラットフォーム、Elasticsearchのbulkエクスポートが失敗したとき、どの行のJSONオブジェクトが壊れているかをすばやく特定する
ストリーミングAPIをデバッグするとき、サーバーが本当に「1行1オブジェクト」で出し続けているか、途中で半端なオブジェクトを先に吐いていないかを確認する
ターミナル、監視ダッシュボード、クラウドのログ画面からコピーしたNDJSONを貼り、まず構造を整えてから調査を続ける
AIが生成した行ごとのオブジェクト結果に、配列や文字列、不完全なJSONがどこかの行に混ざっていないか確認する
ClickHouse、BigQuery、Kafka Connectなど行レベルのレコードに依存する処理に取り込む前に、JSONLの中身を人手で再確認する
監査ログ、リスクイベント、計測イベントストリームをレビューするとき、オブジェクト構造が安定して一貫しているかを1件ずつ見る
JSONLファイルが途中で切れていたりダウンロードが不完全だったりした場合、最後のどのオブジェクトが閉じていないかをすぐに確認する
社内ツールが書き出した改行区切りJSONをまず整形し、コードレビューやデータ確認用に同僚へ送る
JSONLを解析するスクリプトを書く前に、フィールドの階層、ネストされたオブジェクト、配列の位置を人手で確認し、スクリプトのデバッグ時間を減らす
空行と壊れた行が混ざった過去のエクスポートを扱うとき、まず構造上の問題を取り除いてから、CSV変換やDB取り込みに進むか判断する

使い方

JSONLまたはNDJSONの内容を入力エリアに貼り付けます。空でない各行が独立したJSONオブジェクトになっていることを確認してください
右側に行ごとの整形結果がすぐ表示され、壊れた行には行番号・エラー内容・元レコードが示されます
表示に従って該当行を直し、無効行の件数がゼロになるまで繰り返します
すべて有効になったら整形結果全体をコピーするか、データを下流のスクリプト・インポーター・分析処理へ回します

特徴

JSONL / NDJSONを行ごとに解析。手動で先に `[{...},{...}]` のような完全なJSON配列に包む必要はありません
「空でない行はすべて1つのJSONオブジェクト」という実ファイルの意味論に沿って検証。ログ、イベントストリーム、セッションアーカイブなどの一般的なデータ形態にフィットします
左右2ペイン構成：左側の `textarea` に入力し、右側に整形結果をリアルタイム表示。直しながら確認するのに最適です
壊れた行には行番号・パースエラー・元の内容をその場で表示。途中で切れたレコード、閉じ括弧の欠落、結合ミスをすばやく修正できます
すべての空でない行が有効になって初めてコピーを許可。一部だけ成功した壊れかけデータを下流に流しません
全行・非空行・有効行・無効行の件数を内蔵集計。大きなファイルで何件壊れているかをすばやく判断できます
サンプルデータを内蔵。初めて開いた瞬間からJSONL整形を試せます
処理はすべてブラウザ内で完結。ログ、セッションイベント、API出力内容はアップロードされません

JSONLフォーマッター vs JSONフォーマッター vs JSON修復

これらはよく連続して使われますが、解決する問題は異なります。入口を正しく選ぶとずっと速くなります。

ツール	最適な入力	中心となる機能	利用場面
JSONLフォーマッター	1行に1つのJSONオブジェクト	レコード単位で検証・整形	ログ、NDJSON、セッションアーカイブ、ストリーム出力
JSONフォーマッター	完全な1つのJSONオブジェクトまたは配列	JSONドキュメント全体を整形	APIレスポンス、設定ファイル、単発のpayload
JSON修復	構文エラーや非標準なJSONテキスト	まず構文を直してから後続ツールへ	末尾カンマ、コメント、引用符の問題、途中で切れたJSON

Best Practices

デバッグ時は元のJSONL形を保ち、理解のためだけに手動で配列に包まない

下流システムがJSONLを受け取るなら、元の「1行1レコード」の形のまま調べるのが基本です。配列に包めば通常のフォーマッターにはかけられますが、元の行番号の意味論が失われ、実際の壊れた行へ対応づけにくくなります。

大きなファイルは最後の数行を優先して見る

JSONLでは途中の構造が間違っているのではなく、ストリームの中断・ダウンロード失敗・書き込み未完了で最後の数行が切れているケースが多くあります。まず末尾の数レコードを見る方が、先頭から全体をめくるより速いことがほとんどです。

入力にシングルクォート・コメント・JSON5風の記述があるなら、先にJSON修復を使うと時短になる

JSONLページは行ごとのオブジェクト検証に特化しています。元データがそもそも標準JSONでないなら、長いファイルの各行を手で直すより、先に修復してから整形する方が効率的です。

再取り込みするなら「1行1オブジェクト」の転送意味論を必ず保つ

右側の複数行に展開された整形ブロックは人が読むのに向いています。ただしデータをログシステム、メッセージキュー、インポーターへ書き戻すなら、プレビュー形を最終転送形式にせず、元の1行1オブジェクト構造を保ってください。

ファイル全体を目で追うのではなく、行番号を主な手がかりにする

実際の調査で最も速いのは、まず壊れた行番号を特定し、そのレコードを前後の有効レコードと見比べることです。括弧や引用符の欠落、フィールドの途切れ、誤った型の混入のどれなのかが、より速く分かります。

よくある質問

JSONとJSONLの違いは何ですか？

通常のJSONは多くの場合、1つのオブジェクトまたは配列そのもので、1つの完全なドキュメントとしてまとめて解析する必要があります。一方JSONL（JSON Lines、NDJSONとも呼ばれる）は1行に1件の独立したレコードを置く形式で、実務では「1行に1つのJSONオブジェクト」が最も一般的です。行単位で読み・書き・エラー特定ができるため、ログ、イベントストリーム、ストリーム処理、一括取り込みにより適しています。

なぜこのページは「1行に1つのJSONオブジェクト」を重視するのですか？

現実のJSONLファイルの大半、とりわけログ、セッションアーカイブ、イベントストリーム、エクスポートファイルはそのように構成されているからです。お手元のアーカイブ例も典型形で、各行が改行で区切られたオブジェクトになっています。任意のJSON値を広く受け入れるより、この意味論で検証する方が実際のデバッグ場面に合っています。

JSONLは `[{...},{...}]` のようなJSON配列と何が違いますか？

JSON配列は1つの完全なJSONドキュメントで、全体を読み切ってから解析する必要があります。JSONLは各オブジェクトを独立した行レコードに分けるため、ストリームで読め、1件が壊れたときも該当行を直接特定しやすくなります。大きなログファイルやイベントストリームには、まとめた配列よりJSONLの方が向いています。

なぜ空行は無視されるのですか？

空行はコピペ、ログローテーション、手編集などで入りがちで、本来のデータレコードではありません。空行を無視することでノイズを減らしつつ、内容のある行については引き続き厳密にチェックします。

ある行が配列・文字列・`null` だった場合はどうなりますか？

このページでは無効行と判定します。対象フォーマットが「空でない行はすべてJSONオブジェクト」だからです。配列やプリミティブ値を行ごとに保存する必要が本当にあるなら、それはこのページが最適化している典型的なJSONLログ用途ではないということです。

1行でも壊れていると結果全体をコピーできないのはなぜですか？

意図的に保守的な挙動にしています。空でないすべての行が有効な場合だけコピーを許可することで、一部だけ成功した壊れた結果を下流のインポーターやスクリプト、同僚に渡してしまい、二度目の調査が発生するコストを防ぎます。

途中で切れたログファイルも見つけられますか？

はい。JSONLの問題は最後の数行に起きがちです。例えばオブジェクトの `}` や文字列の終端引用符が欠けていたり、ネットワークストリームが途中で切れたり。該当する壊れた行がそのまま表示されるため、不完全なダウンロードやストリーム出力の中断の調査に特に適しています。

JSONLとNDJSONは同じものですか？

ほとんどのエンジニアリング文脈では同義とみなして構いません。どちらも改行で区切られたJSONレコードを指し、呼び方の慣習が違うだけです。

JSONL整形時に自分のデータはアップロードされますか？

いいえ。解析・検証・整形はすべてブラウザ内でローカルに実行され、ログ、APIレスポンス、セッションアーカイブ、データ出力内容がサーバーへ送られることはありません。

通常のJSONフォーマッターではなくJSONLフォーマッターを使うのはどんなときですか？

入力自体が完全なJSONオブジェクトや配列（APIレスポンス、設定ファイル、`[{...},{...}]` のようなデータのかたまり）なら通常のJSON整形ページを使ってください。入力が改行で分かれた1件ずつのオブジェクトレコードである場合にだけ、このJSONL整形ページがより適しています。

用語集

JSONL: JSONレコードを改行で区切るテキスト形式。実務で最も多い書き方は、空でない各行が完全なJSONオブジェクトになっている形です。
JSON Lines: JSONLの正式名称で、もう1つの一般的な呼び名。通常はJSONLと同義とされます。
NDJSON: Newline Delimited JSONの略で、直訳すると「改行で区切られたJSON」。多くのログ・データパイプラインの場面でJSONLとほぼ同義です。
行レコード: 各行が1件の完全なレコードを表すデータ配置。ストリームでの書き込み・読み込みと行単位のエラー特定に適しています。
Pretty Print / 整形: 1行に圧縮されたJSONを、インデントと改行を持つ読みやすい構造に並べ直し、フィールド階層を目視しやすくすること。
壊れた行: 有効なJSONではない行、または解析はできても期待する構造（例：オブジェクトであること）に合わず、有効なJSONLレコードとして扱えない行のこと。
切れたストリーム: 転送・フラッシュ・保存の途中でログやエクスポートが途切れ、最後のレコードが完全に閉じていない状態。
JSON配列: 標準JSONで `[` と `]` に包まれたひとまとまりの集合。例えば `[{...},{...}]`。JSONLと違い、1つのドキュメントとして全体を解析する必要があります。

Authoritative References

jsonlines.orgJSON Lines 公式仕様
IETFJSON 公式規格 RFC 8259