JSONフォーマッター：オンラインでJSONを整形・検証・デバッグ

乱雑なJSONを貼り付けて、きれいな出力を取得。整形・検証・圧縮すべてブラウザ内で完結し、サーバーには一切送信されません。エラーがあれば、どの行が壊れているか正確に教えてくれます。

入力 JSON

JSONデータをここに貼り付け

出力

フォーマットされたJSON結果

インデント：

JSONを60秒で理解する

JSON（JavaScript Object Notation）は、サーバーとブラウザ間でデータをやり取りする標準フォーマットです。あなたが呼び出したすべてのREST APIはJSONを返します。package.json、tsconfig.json、.eslintrcもすべてJSONです。

フォーマット自体はシンプル（オブジェクトは波括弧、配列は角括弧、文字列はダブルクォート）。しかしシンプルさは罠です。コメント構文がない、末尾カンマは違法、カンマ一つ間違えるとドキュメント全体が壊れます。だからバリデーション付きフォーマッターが必要なのです。

JSONはRFC 8259（2017年12月）で定義されています。仕様はたった16ページ。最もつまずきやすいルール：オブジェクトのキーはダブルクォートの文字列でなければなりません。{name: "太郎"} はJavaScriptでは有効ですが、JSONとしては無効です。

使い方

左側の入力エリアにJSONを貼り付けまたは入力。
インデントを選択：2スペース（JS/TS慣例）または4スペース（Python慣例）。
「整形」でプリティプリント、「圧縮」で空白を除去。
結果をコピー。エラーがあれば、バリデーターが正確な行と文字位置をハイライト。

実際の使用場面

APIレスポンスのデバッグ

fetch()が2000文字の塊を返す。ここに貼り付ければネスト構造が一目瞭然。複数のエンドポイントを行き来する時、console.logよりずっと速い。

デプロイ前の設定ファイル検証

CloudFormationテンプレートの末尾カンマを発見？20分のデプロイ失敗を回避できた。プッシュ前にJSON設定をここで検証すれば、エディタのシンタックスハイライトが見逃すエラーもキャッチできる。

データベースエクスポートの整理

MongoDBダンプやFirestoreエクスポートは巨大な1行JSON。整形して、マイグレーションスクリプトをクラッシュさせているnullフィールドを見つける。

ドキュメント用JSONの準備

APIドキュメントやREADMEにJSON例を載せたい？2スペースで整形、コピー、マークダウンのコードブロックに貼り付け。5秒で完了。

経験からのヒント

パースする前に必ずバリデーション

JSON.parse()は必ずtry-catchで囲む。本番環境でキャッチされないJSONパースエラーはNodeプロセスをクラッシュさせるか、ユーザーに白い画面を見せることになる。

コピペのエンコーディング問題に注意

Slack/Wordからのスマートクォート、WindowsメモのBOM文字、Webページの非改行スペース。これらすべて有効に見えるJSONを壊す。バリデーターが位置0でエラーと言ったら、おそらく不可視文字の問題。

オンラインツールを使うべきでない場面を知る

10MB以上のファイルはコマンドラインのjqを使う。CIでの自動整形はprettierやpython -m json.toolを使う。このツールはデスクでの素早い手動デバッグ用で、パイプライン自動化用ではない。

2スペース vs 4スペース

JSON仕様はどちらでもいい。しかしJS/TSプロジェクトは圧倒的に2スペース（人気のOSSリポジトリを見れば分かる）。Pythonプロジェクトは4スペースが多い。一つ選んでチーム内で統一する。

実例

ネストされたAPIレスポンス

典型的なユーザープロフィールAPIレスポンス。ネットワーク上では圧縮された1行形式で送られてくる。

Input

{"id":42,"name":"田中","email":"[email protected]","roles":["admin","editor"],"preferences":{"theme":"dark","locale":"ja","notifications":{"email":true,"push":false}},"lastLogin":"2026-05-10T14:30:00Z"}

Output

{
  "id": 42,
  "name": "田中",
  "email": "[email protected]",
  "roles": [
    "admin",
    "editor"
  ],
  "preferences": {
    "theme": "dark",
    "locale": "ja",
    "notifications": {
      "email": true,
      "push": false
    }
  },
  "lastLogin": "2026-05-10T14:30:00Z"
}

無効なJSON：エラーを見つける

一見正しそうだが、末尾カンマがパースを失敗させる。

Input

{"users": [{"name": "Alice", "age": 30,}, {"name": "Bob", "age": 25}]}

Output

位置38でエラー：予期しない '}' 文字。"30"の後のカンマはJSONでは不正。このカンマを削除して修正。

機能

2スペースまたは4スペースのインデントを選択可能
エラーを正確な行と文字位置で特定
ワンクリック圧縮で本番環境向けに
100%ブラウザ内で動作、データは一切送信されない
50MBのMongoDBダンプでテスト済み
登録不要、広告なし、トラッキングなし

よくある質問

JSONは正しそうなのにパーサーが"unexpected token"と言うのはなぜ？

十中八九これらのどれか：(1) 末尾カンマ（{"a": 1,} は無効）、(2) シングルクォート（JSONはダブルクォートのみ）、(3) クォートなしのキー（{name: "太郎"} はJSだがJSONではない）、(4) コメント（// と /* */ は標準JSONでは不可）。コメントが必要ならJSONCやJSON5を検討。

ファイルサイズの制限は？

こちら側にハードリミットはなく、ブラウザのメモリで動作。Chromeは約100MBまで処理可能で、それ以上はタブがクラッシュし始める。10MB以上はコマンドラインのjqやfxの方がパフォーマンスが良い。

このツールはデータをサーバーに送信する？

いいえ。ページ読み込み後のネットワークリクエストはゼロ。DevToolsのNetworkタブを開いて、JSONを貼り付けて整形をクリックしても何も発火しない。ツール全体がクライアントサイドJavaScript。

JSONとJSONCの違いは？

JSONC（JSON with Comments）は // と /* */ コメントおよび末尾カンマを許可。VS Codeのsettings.jsonやtsconfig.jsonはJSONCを使用。標準JSONパーサーはJSONCを拒否するため、jsonc-parserのような専用パーサーが必要。

なぜJSONは末尾カンマを許可しない？

仕様の意図的な設計で、パースロジックをシンプルかつ明確にするため。JavaScriptは許可、Pythonも許可、しかしJSONは不可。実際の開発で「無効なJSON」エラーの大半は、開発者がJSONも自分のプログラミング言語と同じルールだと思い込むことが原因。

ヒントと関連ワークフロー

整形したJSONをURLパラメータに入れるなら、URLエンコーダー.
Base64エンコードされたJSONペイロードの中身が気になりますか？Base64エンコーダー.
JSONスキーマに正規表現パターンを入れる前のテストに便利です。正規表現テスター.
JSONオブジェクトにユニークIDを付与したいとき、UUID生成ツール.