JSONをオンラインで整形
APIレスポンス、設定ファイル、ログの1行を貼り付けて、読みやすく整えます。オブジェクトと配列を深さに応じてインデントし、キーごとに改行して、結果を構文の色分け付きで表示します。
JSONが圧縮されて届く理由
JSONはAPIで広く使われるデータ形式であり、APIは人の読みやすさより通信量を優先します。RESTエンドポイントやGraphQLサーバーからのレスポンスは、空白なしでシリアライズされます。通信には適していますが、人間には読みにくい形です。ツールが書き出す設定ファイル、構造化ログの各行、ページに埋め込まれたJSON-LD、開発者ツールのネットワークタブからコピーしたデータにも同じことが言えます。
整形すれば構造が一目で分かる
インデントされたJSONなら、構造に関する疑問をすぐに解消できます。オブジェクトがどこまで入れ子になっているか、あるフィールドがオブジェクトの配列なのか配列を持つオブジェクトなのか、値があるはずのどのキーがnullなのか、レコードの区切りはどこかを把握できます。整形されたペイロードなら、欠けたキーやスペルの間違いも数秒で探せます。同じことを1行で行おうとすると、諦めて確認用スクリプトを書くことになりがちです。
不正なJSONをその場で検出
整形して表示する前には入力を解析する必要があるため、整形は手早い構文チェックにもなります。末尾の余分なカンマ、シングルクォートで囲まれた文字列、値の中でエスケープされていない引用符、途中で切れたレスポンスがあると、解析が止まり、結果の代わりにエラーが表示されます。デバッグ中のAPIレスポンスが途中で欠けていたり、設定ファイルにカンマが一つ多かったりすることに、この段階で気付くこともよくあります。
JSON、JSON Lines、JSONPの違い
このページは一つのJSON文書を整形します。1行ごとにJSONオブジェクトが並ぶログファイルの場合は、ファイル全体ではなく、確認したい行を個別に整形してください。全体では一つの有効なJSON文書になっていないためです。また、データが関数名で包まれたレスポンスはJSONではなくJSONPです。JSONのつもりで貼り付けた内容がJavaScriptとして検出されるのは、このためである場合があります。その場合、判定は正しく、JavaScriptとして整形しても十分に読みやすい結果が得られます。
よくある質問
JSONの検証もできますか？
実質的には可能です。整形には文書の解析が必要なため、構文エラーがあると処理が中断され、結果の代わりにエラーが表示されます。ペイロードの構文が正しいかを手早く確認できます。
キーの順序は保たれますか？
はい。キーは元の文書に現れる順序のままで、並べ替えや再配置は行いません。変わるのは空白と改行だけです。
非常に大きなAPIレスポンスも整形できますか？
はい。極端に大きくなければ対応できます。数MB程度のペイロードも処理できますが、解析はご自身の端末内で行うため、少し時間がかかることがあります。外部へのアップロードがないので、社内データを含むレスポンスも安心して貼り付けられます。