JSONフォーマッター & 検証機

JSONとは何か、なぜ文法が厳しいのか

JSON（JavaScript Object Notation）はデータをテキストで受け渡すための形式で、ECMA-404とIETFのRFC 8259で規定されています。名前にJavaScriptとありますが特定の言語に縛られず、 Python、Java、Go、PHPなどほぼすべての言語で同じように読み書きできるため、WebのAPIや設定ファイルの共通言語になりました。文法が小さく厳格なのは、異なるシステムが同じテキストを同じデータとして解釈する必要があるからです。 その代わり、手で書くときはカンマやクォートが1つ違うだけで全体が拒否されます。このツールは、その拒否理由を探しやすい位置と原因の候補に言い換えます。入力はブラウザ内蔵のJSON.parseで端末上で処理され、このページのスクリプトにはネットワーク通信がないため、貼り付けた内容が送信・保存されることはありません。

使える値は6種類

日付専用の型はないため、ISO 8601形式の文字列（例：2025-01-01T00:00:00Z）か数値のタイムスタンプで表すのが一般的です。バイナリデータも直接は入れられず、Base64で文字列に変換して入れます。 システム間のやり取りでは、RFC 8259はUTF-8の使用を求めています。

よくある文法エラー8つと直し方

実務で見る誤りの大半はこの8つです。解析に失敗すると、ツールは文字列の中身を除いて入力を走査し、当てはまりそうなものを「考えられる原因」として列挙します。あくまで目安であり、複数出ることも、何も出ないこともあります。

エラー位置の求め方

ブラウザは「位置57」のような0始まりの文字位置、新しいエンジンでは行と桁を報告します。位置だけが分かる場合は、その手前の改行の数から行番号を、最後の改行からの文字数から桁を計算し、該当行とキャレット（^）を表示します。 大事なのは、パーサーが報告するのは「問題に最初に気づいた場所」で、間違えた場所とは限らないという点です。ペアの間のカンマが抜けていると、エラーは隙間ではなく次のペアの先頭を指します。示された位置の直前も必ず見てください。 ブラウザによって文言や位置の形式が違うため、位置が取れない場合は元のメッセージと原因の候補だけを表示します。

整形と圧縮の使い分け

2つは意味が同じで、空白だけが違います。人が読んで編集する設定ファイルやログには整形、リクエスト本文、URL、環境変数、Cookieに入れるときは圧縮が向いています。 下の大きさは、このページのビルド時に同じ小さなオブジェクトを各形式に変換して測ったUTF-8のバイト数です。

{
  "name": "山田太郎",
  "age": 30,
  "tags": [
    "a",
    "b"
  ],
  "address": {
    "city": "東京"
  }
}

この例では圧縮するとスペース2つの整形版より約34%小さくなります。入れ子が深いほど差は広がりますが、サーバーがgzipやBrotliで圧縮して送るなら通信量の差はずっと小さくなります。タブが小さいのは、1段のインデントが1バイトで済むためです。

変換で値が変わる3つの例（実行して確認済み）

JSONは「テキスト→値→テキスト」を通るため、整形しただけで内容が変わることがあります。以下はビルド時に実際に実行した結果です。

例1：大きな整数の桁落ち

{"id":12345678901234567890}を解析して再出力すると、idは12345678901234567000になります。JavaScriptの数値は64ビット浮動小数点なので、正確に扱える整数は9007199254740991（2の53乗−1）までだからです。 SNSの投稿IDや注文番号のように16桁前後を超える整数は、文字列で受け渡すのが定石です。入力に安全な範囲を超える整数があると、ツールは警告を出します。

例2：キーの順序、重複キー、数値の表記

{"b":1,"2":2,"1":3}は出力すると{"1":3,"2":2,"b":1}になります。JavaScriptは"1"や"2"のような整数形式のキーを先に昇順で出すため、この場合は元の順序が保たれません。{"a":1,"a":2}のようにキーが重複する場合、RFC 8259は名前は一意であるべき（SHOULD）としつつ挙動を定めておらず、ブラウザは最後の値を残して{"a":2}にします。 数値も正規化され、[0.1,1e3,1.0,-0]は[0.1,1000,1,0]になります。1e3は1000、1.0は1、−0は0です。意味は同じですが、署名やハッシュの検証のように一文字単位の一致が要るデータには、整形後の結果を使わないでください。

例3：キーをソートして2つのJSONを比べる

別々のシステムが同じデータをキーの順序違いで出力すると、目視の比較は大変です。それぞれ「キーを名前順に並べ替え」で整形し、テキスト差分チェッカーに貼れば、本当に違う部分だけが残ります。 配列は順序に意味があるためそのまま、並べ替えるのはオブジェクトのキーだけです。

限界と使ってはいけない場面

• 標準のJSONのみ対応です。コメントや末尾のカンマを許すJSON5やJSONC（エディタの設定ファイルなど）はエラーになります。先にコメントを消してください。
• 1行に1つのJSONが並ぶJSON Lines（NDJSON）は、全体を一度に貼るとエラーになります。1行ずつ検証してください。
• 数十MB級のファイルはブラウザが固まることがあります。大きなデータはコマンドラインツールやエディタで処理してください。
• 検証するのは文法だけです。必須のキーがあるか、型が合っているかはJSON Schemaのようなスキーマ検証の領域です。
• 送信はされませんが、パスワードやトークン、個人情報は、共用PCや画面共有中には貼り付けないほうが安全です。

使いどころ

• APIが400エラーで拒否されたとき：まずリクエスト本文を検証して文法の誤りを除外し、次にサーバーが求める項目を確認します。
• 設定ファイルを編集したあと：保存前に「検証のみ」を押して、アプリが起動しなくなる事故を防ぎます。
• ログの圧縮JSONが読めないとき：整形してから正規表現テスターで必要な部分を抜き出します。
• クエリ文字列にJSONが入っているとき：URLエンコーダーでデコードしてから貼り付けます。

よくある質問