MT
My Toolbox

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としては無効です。

使い方

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

実際の使用場面

APIレスポンスのデバッグ

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

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

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

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

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

ドキュメント用JSONの準備

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

経験からのヒント

1.

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

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

2.

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

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

3.

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

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

4.

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エンコーダー.
  • APIトークンを扱っていますか？Base64エンコードされたJSONペイロードをデコードするには、Base64エンコーダー.
  • JSONスキーマで使う前に正規表現パターンを検証するには、正規表現テスター.
  • JSONオブジェクトにユニークな識別子を生成するには、UUID生成ツール.