オンラインで JSON をフォーマット・検証する方法

API、設定ファイル、または構造化データのあらゆる種類で作業する場合、JSON を定期的に扱います。そして、欠落しているブラケットを見つけようと最小化された JSON の壁を見つめたことがあるなら、フォーマットが重要な理由を知っています。ブラウザベースのフォーマッタは、データをサーバーにアップロードせず、すべての作業をローカルで処理します。

JSON フォーマットがすること

API レスポンスや最小化されたファイルからの生 JSON は次のようになります:

{"users":[{"name":"Alice","age":30,"roles":["admin","editor"]},{"name":"Bob","age":25,"roles":["viewer"]}]}

フォーマッタはそれを読みやすいものに変換します:

{
  "users": [
    {
      "name": "Alice",
      "age": 30,
      "roles": ["admin", "editor"]
    },
    {
      "name": "Bob",
      "age": 25,
      "roles": ["viewer"]
    }
  ]
}

同じデータですが、実際に読み取り、エラーを見つけ、構造を理解できるようになりました。

オンラインで JSON をフォーマットする方法

1. JSON を貼り付け: 入力フィールドに貼り付けます。フォーマッタは即座に構文エラーを検出し、構造を検証します。
2. インデントを選択: 2 または 4 スペースを選ぶか、Minify をクリックして JSON を 1 行に圧縮します。
3. 結果をコピー: フォーマットされた出力には色分けされた構文ハイライトが含まれます。コード、設定ファイル、またはドキュメントで使用するためにコピーします。

JSON の簡単な歴史

JSON(JavaScript Object Notation)は Douglas Crockford によって 2001 年に仕様化され、2006 年に RFC 4627 で正式に文書化され、2013 年に ECMA-404、2017 年に ISO/IEC 21778 として標準化されました。Crockford は JSON を発明したわけではありません: 既に使われていた JavaScript オブジェクトリテラル構文のサブセットから抽出し、名前と json.org の 1 ページの仕様を与えました。

JSON は劇的にシンプルだったため、ウェブ API で XML を急速に取って代わりました。XML レスポンスは開始/終了タグで冗長ですが、同等の JSON はサイズの半分です。ブラウザは XML パーサーなしで JSON をネイティブに解析できます(JSON.parse、JSON.stringify は 2009 年の ECMAScript 5 以降)。

2015 年までに、世界のすべての主要 API が JSON を話しました: REST API、GraphQL クエリ、WebSocket メッセージ、設定ファイル(package.json、tsconfig.json、.vscode/settings.json)、さらにはデータベース(PostgreSQL JSONB、JSON のような MongoDB BSON)。ウェブ上の構造化データの共通言語になりました。

JSON のシンプルさはその制限でもあります: コメントなし、末尾カンマなし、日付型なし、バイナリサポートなし。これらのギャップに対処するために、いくつかの JSON バリアントが登場しました(下記の「代替 JSON 風フォーマット」を参照)。

よくある JSON エラーと見つけ方

ほとんどの JSON エラーは、いくつかの一般的な間違いに帰着します:

• 欠落または余分なカンマ: 配列やオブジェクトの最後の項目の後のカンマは JSON では無効です(JavaScript とは異なり)
• 引用符のないキー: JSON はすべてのキーに二重引用符を必要とします: "name"、name ではなく
• 単一引用符: JSON は二重引用符のみを受け入れます: "value"、'value' ではなく
• 末尾カンマ: {"a": 1,} は無効です。最後のエントリの後のカンマを削除します
• コメント: JSON は // 行 や /* ブロック */ コメントをサポートしません。ほとんどのパーサーはそれらを拒否します
• undefined / NaN / Infinity: JSON は数値、文字列、ブール値、null、配列、オブジェクトのみを許可します。undefined、NaN、Infinity のような JavaScript 値は無効です
• 関数値: 関数参照は JSON に出現できません
• 16 進数または 8 進数: 10 進数のみが有効です(0xFF や 0o17 は無効)
• 先頭ゼロ: 01 は JSON で無効です。1 を使用してください
• 16 進エスケープ: 文字列では \u Unicode エスケープのみが許可されます、\x や \0 ではありません
• 重複キー: 仕様上は技術的に有効ですが、ほとんどのパーサーは静かに最後の値を使用します。自己責任で頼ってください
• UTF-8 BOM: ファイルの先頭のバイト順マークは有効な JSON ではなく、厳密なパーサーを壊します
• 末尾の空白またはコンテンツ: 閉じる ] や } の後のテキストは文書を無効にします

良いフォーマッタはエラーがどこにあるかを正確にハイライトするので、推測する代わりに即座に修正できます。

JSON データ型

JSON にはちょうど 6 つのデータ型があります:

特に欠けているもの: 日付(ISO 8601 文字列を使用)、バイナリデータ(Base64 文字列を使用)、コメント(別のドキュメントフィールドを使用)、bigint(JSON 数値は倍精度、2^53 以上の値は精度を失います)。

フォーマットと最小化を使い分け

フォーマット(整形表示)は次の場合に必要:

• データを読み理解する
• API レスポンスをデバッグする
• 設定ファイルを編集する
• 同僚と JSON を共有する
• バージョン管理にコミット(よりクリーンな差分)

最小化は次の場合に必要:

• ネットワーク経由でデータを送信(より小さいペイロード = より高速な転送)
• 可読性が重要でないデータベースやログに JSON を保存
• URL パラメータやフォームフィールドに JSON を埋め込む
• コンパクトな API レスポンスを生成

サイズの違いは重要です: 典型的な 50 KB の整形 JSON は最小化で約 30 KB になります。高トラフィック API では、最小化されたレスポンスが帯域幅を節約します。人間が編集するファイルには、フォーマット済みが不可欠です。

代替 JSON 風フォーマット

JSON の厳密さが問題のとき、いくつかのバリアントがルールを緩和します:

データ交換(API レスポンス、設定)には、厳密な JSON を使用してください。人間が編集する設定には、JSON5 や JSONC がより親しみやすいです。データストリーミングには、NDJSON がデファクト標準です。

よくある落とし穴

• 数値が精度を失う: JSON 数値は IEEE 754 倍精度です。2^53(9,007,199,254,740,992)を超える整数は精度を失います。大きな ID を文字列として送信してください("id": "12345678901234567890")。
• Unicode エスケープがエディタで破損: 一部のエディタは保存時に文字を自動変換し、パーサーが予期しない動作をすることがあります。全体で UTF-8 を使用してください。
• 日付の整形が間違っている: ISO 8601 文字列としての日付("2026-05-20T13:00:00Z")が標準です。Unix タイムスタンプを文字列として避けてください。数値のように見えますが、通常は日付として意図されています。
• キー内の空白: {"first name": "..."} は有効な JSON ですが、識別子安全なキーを期待する多くの ORM やコードジェネレーターを壊します。
• 空の値と欠落キー: {"a": null} と {}(a が全くない)は異なるものです。1 つの規約を選び、文書化してください。
• Bigint の不一致: PostgreSQL bigint カラムを JSON 数値としてシリアル化すると精度を失うことがあります。2^53 以上の ID には文字列を使用してください。
• 末尾改行: 一部のツールは閉じ括弧の後に末尾改行を追加します。一部の厳密なパーサーはそれを拒否します。JSON-stringify は末尾改行を生成しません。
• エンコーディング不一致: JSON 仕様は UTF-8(または BOM 付き UTF-16/UTF-32)を要求します。非 ASCII 文字を含む Latin-1 は失敗します。常に UTF-8 としてシリアル化してください。
• JSON 内の文字列化された JSON: ネストされたエスケープ文字はすぐに扱いにくくなります。オブジェクトを直接ネストするか、base64 エンコードされた JSON 規約を選んでください。
• ソースファイル内のコメント: JSONC や JSON5 を厳密な JSON を期待するシステムにチェックインすると、解析が失敗します。ビルドステップで厳密な JSON に変換してください。

JSON 作業のヒント

• 送信前に検証: 手動で API リクエストを構築する場合は、まず JSON をバリデータに貼り付けてください。単一の誤配置のカンマがサーバー側で混乱するエラーを引き起こすことがあります。
• 深くネストされたデータには 2 スペースインデントを使用してください。行を短く保ち、構造をスキャンしやすくします。
• ツールをブックマーク: 定期的に JSON を扱う場合、フォーマッタが 1 クリックで利用できることで、毎回検索するよりも時間を節約します。
• コマンドライン作業に jq を使用: jq(および gron、dasel、yq のような jq 言語の代替)は、コマンドラインで JSON をフィルタリングおよび変換するのに不可欠です。
• 検証に JSON スキーマを使用: 重要なフォーマット(API 契約、設定ファイル)には、JSON スキーマを定義し、それに対して検証してください。ajv(JavaScript)、python-jsonschema、または VS Code の組み込みスキーマ検証のようなツールが形状エラーを防ぎます。
• API リクエストに Postman または Insomnia を使用: これらのツールには組み込みの JSON フォーマッタとバリデータ、構文ハイライト、リクエスト履歴があります。
• コードベースで JSON を prettier に通す: Prettier は JSON を一貫してフォーマットします。フォーマットが決してコードレビューの懸念にならないように、プリコミットフックとして統合してください。
• 差分を取るためにキーをまずソート: JSON オブジェクトのキーは順序がありません。{"a":1,"b":2} と {"b":2,"a":1} の差分は、まずキーをソートしない限りすべてが変更されたように表示されます。jq -S または同様のものを使用してください。

プライバシーと機密 JSON

JSON フォーマッタは完全にブラウザ内で動作します。貼り付ける JSON、中間処理、フォーマットされた出力のすべてがデバイス上に残ります。サーバーへのアップロードも、ログ記録も、誰かとの共有もありません。

これが重要なのは、JSON が非常に機密性の高いデータを含むことがよくあるからです: 顧客レコードとメールアドレスを含む API レスポンス、認証トークンとセッションデータ、製品アーキテクチャを明らかにする内部 API スキーマ、データベースパスワード付き設定ファイル、会計 API からの財務データ、FHIR API からの医療記録、HR API からの内部企業構造、インフラを明らかにするスタックトレース付きデバッグペイロード。クラウド JSON フォーマッタはすべての貼り付けをリクエストログに記録し、「サービス改善」のために保持することがあり、貼り付けられた API レスポンスが顧客データと API キーを漏洩した実際のインシデントに関与してきました。ブラウザベースのフォーマッタはエクスポージャーがゼロです: JSON は決してマシンを離れません。

ブラウザベースのフォーマットは、ページが読み込まれた後はオフラインでも機能します。飛行機内、インターネットアクセスのないセキュア環境、またはサードパーティサービスに API データ(特に資格情報が埋め込まれているもの)を貼り付けることができない、すべきでない場所での JSON フォーマットに便利です。