ツール修正（2026年10月9日）： 旧版は大きな数値の桁を変え、1e999 を null にし、重複項目を失っていました。整形・圧縮・キー整列・ツリーとコピー結果は、数値表記・文字列のエスケープ・全項目をそのまま保持する方式に修正しました。他の処理ですでに丸められた桁は復元できず、本番の秘密情報の安全も保証しません。
テスト用 API レスポンスを貼り付けたら、赤い一行に Unexpected token。どこが悪いのか目で追ううちに、結局は括弧をひとつずつ数えている。JSON はルールが単純なのに、その単純さゆえに小さなミスひとつが全体のパースを止めます。まずは、どこが壊れているかを見つける方法から整理します。
壊れた JSON、まずはどこが問題か
JSON パーサーは最初の構文エラーで止まります。ブラウザが位置情報を返せば、PiPi の JSON フォーマッターも行・列を表示します。訂正（2026年9月28日）：旧版は1行のコードを掲載しながら「4行目のエラー」と説明していました。実際に4行ある例に修正しました。 図はAIで制作した編集用画像で、実際のツール画面ではありません。
次は4行のテスト入力です。
{
"name": "PiPi",
"role": "editor",
}
現在のChromium/V8では Expected double-quoted property name in JSON at position 40 (line 4 column 1) と表示されます。不要なカンマは3行目の末尾にあり、パーサーは4行目の } に達した時点で次のプロパティ名を期待して止まります。"editor" の後のカンマを消せば有効です。 同じ内容を { "name": "PiPi", "role": "editor", } と1行で入力した場合は、4行目ではなく1行目のエラーです。文言と位置情報の有無はブラウザのエンジンによって異なります。
よく出るエラーは決まっています。
| エラー | 症状 |
|---|---|
| 末尾カンマ | 最後の要素の後の余分なカンマ |
| クォート抜け | キーや文字列をダブルクォートで囲んでいない |
| 括弧の不一致 | {・[ を閉じていない |
| コロン抜け | キーと値の間の : がない |
JSON はシングルクォート・コメント・末尾カンマを許可しません(RFC 8259)。JavaScript のオブジェクトリテラルと混同して起きるミスが多いです。
見やすく整形するか、一行に圧縮するか
有効な JSON なら、インデントを付けて構造を一目で確認できます。2スペース・4スペース・タブから、チームの規約に合うものを選べます。
逆に転送サイズを抑えたいときは、圧縮で文字列の値の外にある不要な空白を取り除きます。{ "a": 1, "b": [1, 2, 3] } は {"a":1,"b":[1,2,3]} の一行になります。同じデータを表示用と転送用で行き来する作業なので、出番は多いです。
キー整列: 2つの API レスポンスを行単位で比較する
あまり知られていませんが、デバッグで便利なのがキー整列です。通常の文字列キーは JavaScript の文字列比較順で並べ替えます。ただし、"2"・"10" のような整数インデックスのキーは JSON 出力時に数値順で先に表示されます(MDN JSON.stringify)。
2台のサーバーが同じデータを返すのに、キーの順序だけが違って diff が真っ赤になった経験はありませんか。両方をキー整列でそろえると、順序による差分を減らして比較しやすくなります。たとえば {"name":"PiPi","id":42,"active":true} は active・id・name の順に並び替えられます。修正後は元の数値表記と重複項目を保持し、重複キーを警告します。別のパーサーは前の項目を上書きする場合があります。整列結果だけで2つの応答の値が等しいとは判断しないでください。
精度低下: 修正後のツールと別の処理の違い
**10月9日修正前の JSON.parse/JSON.stringify 方式の例であり、現在の PiPi の出力ではありません。**JSON の数値は JavaScript で IEEE-754 倍精度としてパースされます。
問題は安全な整数の範囲を超えるときです。{"id": 12345678901234567890} を旧方式で変換すると {"id": 12345678901234567000} が出てきます。下の桁が静かに 000 に変わったのです。JavaScript の安全な整数の最大値は 2^53−1、つまり 9007199254740991 です(MDN)。Discord や Twitter の ID のような大きな整数は、この範囲を簡単に超えます。正確な桁が必要なら、元の JSON でその値を文字列("12345678901234567890")にしておくのが安全です。機密性のないテストデータで、この罠を確認できます。
現在のツールは、全モードとコピー結果で 12345678901234567890・0.123456789012345678901・1e999・-0 を入力どおり保持します。{"same":1,"same":2} の両項目も残し、重複を警告します。数値の原文保持は計算や別の処理の表現可能範囲の保証ではありません。
その API レスポンス、どこに貼っていますか
最後に押さえる点です。デバッグ用 JSON には、アクセストークンや内部 ID、個人情報が混ざることがあります。オンラインフォーマッターに貼り付けると漏えいの恐れがあります。先に例や機密性のないテスト値に置き換えてください。
PiPi Worlds の JSON フォーマッターは解析処理自体をブラウザ内で実行しますが、それだけで本番の秘密情報の安全は保証できません。サンプル JSON の Base64 値は Base64 ツールで、テスト用 JWT の構造は JWT デコーダーで確認できます。本番の秘密情報には承認済みのローカル手順を使ってください。