先讀懂資料結構，再調整空白與縮排
JSON 格式化線上工具 — 語法驗證、壓縮與 JSONPath 查詢
格式化能讓合法的 JSON 更好讀，卻不會自動修好語法，也不能證明資料內容可信。DevSexy 將排版與語法驗證分開，解析器有提供 offset 時，會一併顯示錯誤所在的行與欄。
原始 JSON
{"user":{"id":17,"roles":["editor"]}}解析結果
物件 · 1 個根層鍵 · 2 個巢狀值
節點路徑
$.user.roles[0] → “editor”
從原始 JSON 走到可追蹤的樹狀結構
錯誤位置怎麼看
行號與欄號是線索；真正漏掉的符號常在前一個 token。
少了逗號或引號時，解析器可能直到下一個欄位才確定語法無法繼續。診斷會保留原始錯誤訊息；若執行環境有回傳字元 offset，介面也會換算成行、欄位置，協助回頭檢查真正出錯的邊界。
2 "name": "Mole" 3 "active": true 4 "roles": ["admin"] ▲ 這個欄位前面少了逗號
排版選項會改變 diff；解析與重新序列化仍有資料邊界
縮排方式
2 個空白較精簡，4 個空白容易逐層掃讀，Tab 則可配合編輯器規範。輸出會重新序列化，因此數字寫法與跳脫字元的表面形式不保證原樣保留。
鍵名排序
遞迴排序鍵名能讓 fixture 與 snapshot 比較穩定，但會打亂人工安排的閱讀順序，所以必須由你主動開啟。
JSON 壓縮
這裡的壓縮是 parse 後再移除不具語意的空白，並非 ZIP 或字串壓縮。重複鍵、超出 JavaScript 安全整數範圍的數字與原始數字寫法不保證保真。
標準 JSON 不等於 JSONC
RFC JSON 不接受註解、尾端逗號、未加引號的鍵、NaN 或 Infinity。開啟 JSONC 選項後，本工具可接受註解與尾端逗號；但壓縮或針對查詢結果輸出時，會序列化解析後的值，不會保留註解。
✓ 標準 JSON：字串、數字、布林值、null、陣列與物件
× JSONC 擴充：註解與尾端逗號，必須明確開啟選項
先通過 JSON 語法驗證，再執行 JSONPath
對無法解析的文件下查詢，只會得到誤導性的結果。目前支援根節點、點號成員、陣列索引與 * 萬用選取等基本路徑；不宣稱支援 RFC 9535 的篩選器、slice、union 或遞迴下降等完整語法。
$.users[0].id$.users[*].email$.orders[*].status執行這些 JSON 範例
先對照輸入與預期結果，再將相同資料和選項載入編輯器。
載入範例會取代目前的輸入與處理選項。
格式化標準 JSON 資料
格式化 · 2 個空白縮排 · 關閉 JSONC · 關閉鍵名排序 · JSONPath 根節點。
輸入
{"user":{"id":17,"roles":["editor"]},"active":true}預期結果：保留相同解析值的巢狀物件，並顯示容易閱讀的縮排。
{
"user": {
"id": 17,
"roles": [
"editor"
]
},
"active": true
}將含註解的設定轉成標準 JSON
壓縮 · 開啟 JSONC · JSONPath 根節點。關閉 JSONC 後，可看出相同輸入為何無法依標準 JSON 解析。
輸入
{
// local development
"port": 3000,
"enabled": true,
}預期結果：序列化後的 JSON 不再包含註解與尾端逗號。若選擇格式化並開啟 JSONC，則可保留註解。
{"port":3000,"enabled":true}繼續處理資料的下一步
語法正確不代表必要欄位與型別正確；接著依你的 schema 驗證資料。
YAML 與 TOML 應交給設定檔工具處理，不能直接當成 JSON 解析。
兩份資料使用一致的縮排與鍵名排序設定，再比對版本差異。
用快捷鍵隨時開啟格式化與檢查工具，並在本機離線處理。