JSON整形と圧縮の使い分け｜迷ったらこの表で判断

30秒結論

状況	選択	理由
デバッグ・内容確認	整形	目で追えないと意味がない
コードレビュー	整形	差分が読みやすい
Git管理	整形	Diffが明確になる
設定ファイル	整形	人が編集する前提
API通信	圧縮	通信量削減
LocalStorage保存	圧縮	容量節約
ログ出力（1行1レコード）	圧縮	grep しやすい

迷ったときの判断基準: 人が読む → 整形、マシンが処理する → 圧縮

---

整形（prettify）を使う場面

人の目に触れるなら整形する。

デバッグ・内容確認

APIレスポンスが1行で返ってきても、整形すれば構造がわかる。

// 圧縮状態（読めない）
{"user":{"id":1,"name":"田中","roles":["admin","editor"]},"meta":{"version":"2.0"}}

// 整形後（読める）
{
  "user": {
    "id": 1,
    "name": "田中",
    "roles": ["admin", "editor"]
  },
  "meta": {
    "version": "2.0"
  }
}

Git管理・コードレビュー

整形済み + キーソート済みで保存すると、Diffが読みやすい。

# pre-commitフックで自動整形する例
npx prettier --write "*.json"

圧縮状態だと、1文字の変更でも行全体が変更扱いになる。

---

圧縮（minify）を使う場面

マシンが処理するなら圧縮する。

API通信

整形済みJSONを送っても動作はするが、無駄な通信量が増える。

// 自動的に圧縮形式で送信される
fetch('/api', {
  body: JSON.stringify(data),
});

サイズ差の目安

{
  "name": "example",
  "items": [1, 2, 3]
}

形式	サイズ
整形（2スペース）	48バイト
圧縮	35バイト

小さいJSONでも約30%の差。大きいJSONほど差が開く。

---

インデント幅の選び方

幅	特徴	向いている場面
2スペース	省スペース、Web標準	JavaScript/TypeScript プロジェクト
4スペース	深いネストでも見やすい	Java/Python 界隈
タブ	表示幅を各自で調整可能	アクセシビリティ重視のプロジェクト

チームで統一されていればそれに従う。なければ 2スペースが無難。

---

キーソートを使う場面

比較前の正規化

同じデータでもキーの順序が違うとDiffが出る。

// ファイルA
{"b": 2, "a": 1}

// ファイルB
{"a": 1, "b": 2}

両方をソートしてから比較すれば、本質的な差分だけが見える。

いつ使う？

場面	キーソート
2つのJSONを比較	ON
設定ファイルをGit管理	ON
APIレスポンスをそのまま保存	OFF（順序に意味がある場合）

---

よくある間違い

「整形してからAPIに送る」

動作はするが、無駄。JSON.stringify() は自動的に圧縮形式で出力する。

「ログを整形して出力」

複数行になると grep しにくい。1行1レコードが基本。

# 圧縮形式なら grep できる
cat logs.json | grep "error"

「比較するときソートしない」

キー順序の違いがノイズになる。比較前にソートを習慣にする。

---

まとめ

判断軸	選択
人が読む	整形
マシンが読む	圧縮
比較する	キーソート
インデント迷う	2スペース

👉 JSON Formatter で整形・圧縮・キーソートがワンクリック