有効なJSONを安全に整形・圧縮する方法
有効なJSONの空白だけを整え、文字列、数値、Unicode、エスケープ、プロパティ順序への影響を確認して再検証します。
公開日: 2026-08-10 · 更新日: 2026-08-10
整形と圧縮の違い
整形は、構造が読みやすくなるようにJSONの構造文字の周囲へ改行やインデントを加える処理です。圧縮は、同じデータを表すために不要な空白や改行を取り除く処理です。どちらも入力が有効なJSONであることが前提で、値や配列要素を変更する処理ではありません。
{ "name": "App Museum", "tags": ["web tool", "JSON"] }
2スペースで整形した期待結果は次のとおりです。
{
"name": "App Museum",
"tags": ["web tool", "JSON"]
}
この結果を圧縮すれば、最初の1行へ戻ります。App MuseumのJSON整形ツールは入力をparseし、2スペース、4スペース、または空白なしで再serializeします。
文字列内の空白はデータである
JSONでは、オブジェクトや配列の構造文字の前後に置ける空白と、ダブルクォート内の文字列を区別します。"display name" の空白や "a b" の連続する2個の空白は値の一部なので、圧縮しても削除・統合してはいけません。
input: { "message": "red blue", "line": "a\nb" }
minified: {"message":"red blue","line":"a\nb"}
単純な空白削除や改行削除では、文字列の値を壊したり、エスケープされた引用符の境界を誤認したりします。JSONパーサーで構造を読み取ってからserializeする方法を使います。
parse後の再serializeで確認するもの
parseと再serializeは意味上同じJSON値を作るための一般的な方法ですが、元の文字表現をそのまま保存する処理ではありません。
- JSONオブジェクトのプロパティ順序をデータの意味として扱わないでください。利用先が順序へ依存するなら、その契約自体を見直す必要があります。
éと\u00e9、/と\/のように、同じ文字列を表すエスケープ表記が別の見た目で出力されることがあります。- 改行、引用符、バックスラッシュなど、必要なエスケープが保持され、再parse後の文字列値が一致するか確認します。
- 非常に大きい数、小さい数、長い小数は、パーサーの数値型で精度や表記が変わる可能性があります。識別子や桁を厳密に保つ値は文字列として設計します。
- Unicode文字は出力上の見た目だけでなく、再parse後のコードポイント列が必要な要件を満たすか確認します。
署名対象のバイト列、差分を最小化したい設定ファイル、元のエスケープ表記を保存すべき文書では、再serializeした結果へ無条件に置き換えないでください。
構文エラーは先に解消する
末尾のカンマ、シングルクォート、閉じ括弧の不足などがある入力は有効なJSONではないため、安全に整形・圧縮できません。エラーが出たら、まず関連ガイド「JSONの構文エラーを見つけて修正する方法」に従って作業用コピーを修正します。
整形ツールが構文エラーを表示した状態で、正規表現や一括置換によって空白だけを削除するのは避けてください。エラーのある構造と文字列内の空白を区別できないためです。このガイドは、構文修正後の有効なJSONだけを対象にしています。
整形・圧縮後に再検証する
- 元のJSONを変更せずに保存します。
- JSON整形ツールでparseエラーがないことを確認します。
- 読む用途なら2または4スペースで整形し、転送量を減らす用途なら圧縮します。
- 出力をもう一度ツールへ入力し、再び正常にparse・整形できることを確認します。
- オブジェクトのキー集合、配列の順序と要素数、各値の型と内容を元データと比較します。
- 大きな数、Unicode、改行やバックスラッシュを含む文字列を重点的に確認します。
可能なら、元のJSONをparseした値と出力をparseした値を構造として比較します。文字列としての完全一致は、インデントやエスケープ表記が変わるため適切な判定になりません。最後に、実際の利用先でもスキーマや必須項目を検証してください。JSONとして有効であることだけでは、利用先の契約までは保証されません。
参考資料
このガイドで使えるアプリ
関連ガイド
- JSONで起きやすい引用符、カンマ、キー、数値のエラーを切り分け、安全に修正する手順を解説します。開発者向けjsonsyntax-errordebugging