JSON 格式化把壓成一行的 API 回應攤開成有縮排的結構，也能反過來把排版好的 JSON 壓成最小體積。轉換用的是瀏覽器內建的 JSON 解析器，你貼上的內容不會離開這台電腦——這對 JSON 特別重要，因為實務上貼進格式化工具的往往是含有 access token、訂單資料或客戶 email 的 API 回應。
使用步驟
- 把 JSON 貼進上方輸入框。壓成一行的、換行亂掉的、從瀏覽器 DevTools 複製出來的都可以。
- 選縮排：2 個空格（多數 JavaScript 專案的慣例）、4 個空格，或 Tab。
- 按「格式化」攤開結構，或按「壓縮」移除所有多餘空白。
- 解析失敗時會顯示瀏覽器回報的錯誤訊息，並標出出錯位置在第幾行附近。
- 結果用右上角的複製按鈕帶走。輸入框內容不會被送到任何伺服器，關掉分頁就消失。
什麼時候用得上
看懂壓縮過的 API 回應
正式環境的 API 幾乎都回傳無空白的單行 JSON。貼進來格式化後，巢狀層級一眼看得出來，比在終端機裡瞇著眼睛數括號快得多。
手改設定檔後先驗證再存檔
package.json、tsconfig.json、composer.json 手動編輯後最容易多一個逗號。先貼進來按格式化，有錯會直接告訴你在第幾行，不必等到 build 失敗才發現。
把兩份 JSON 拉成可比對的格式
要 diff 兩份來源不同的 JSON 時，先各自用相同縮排格式化，diff 才會只顯示真正的差異，而不是被排版差異塞滿。
送出前縮小 payload
寫進環境變數、塞進 QR code、或放進 URL 參數的 JSON 需要越短越好。壓縮會移除所有縮排與換行，內容不變但體積通常少 20–40%。
限制與注意事項
- 這裡走的是嚴格 JSON 規格，不是 JavaScript 物件語法。尾逗號、單引號、
// 註解、未加引號的 key 都會被判為錯誤——這不是工具的限制，而是 JSON 規格本來就不允許。 - 超過 2^53（約 9007 兆）的整數會失去精度。雪花演算法產生的 ID、Twitter/Discord 的 message ID 這類長數字，格式化後尾數可能變動。若要保留原值，請讓後端把它們當字串傳。
- 同一層出現重複的 key 時，只有最後一個會被保留，這是 JSON 解析器的標準行為。
- 解析是同步進行的，整份資料會載入記憶體。幾百 KB 沒問題，但數十 MB 的檔案會讓分頁凍結幾秒；那種規模建議用命令列的
jq。 - 這個工具只做格式化與壓縮，不做 JSON Schema 驗證、不排序 key、不支援 JSONPath 查詢。它回報的是「語法是否合法」，不是「結構是否符合你的預期」。
常見問題
我的 JSON 看起來完全正常，為什麼一直說有錯？
最常見的四個原因：物件或陣列最後一個元素後面多了逗號；字串用單引號而不是雙引號；key 沒有加引號；檔案裡有 // 或 /* */ 註解。這四種寫法在 JavaScript 裡都合法，在 JSON 裡都不合法。另一個容易忽略的是從網頁複製時帶進來的不可見字元，例如全形空格或 BOM。
我貼上的資料會被上傳嗎？
不會。格式化用的是瀏覽器內建的 JSON.parse 與 JSON.stringify，在你的裝置上執行完就結束，沒有任何請求帶著輸入框的內容出去。你可以把網路斷線後再操作一次驗證這件事——工具仍然正常運作。頁面本身會載入廣告等第三方資源，那些請求不包含你貼上的任何資料。
壓縮會不會改變我的資料？
值不會變，但有兩件事會變：所有縮排與換行被移除，以及數字會被正規化（1.0 變成 1、1e3 變成 1000）。如果你的系統會對 JSON 字串做簽章或計算雜湊，壓縮前後的結果不會相同。
為什麼錯誤訊息的措辭每台電腦不太一樣？
錯誤訊息直接來自瀏覽器的 JavaScript 引擎，Chrome（V8）、Firefox（SpiderMonkey）與 Safari（JavaScriptCore）的用字各不相同。「第幾行附近」這個提示是本工具依照引擎回報的字元位置換算出來的，指的是解析中斷的位置，真正的問題有時在前一行。
可以格式化 JSON Lines（每行一筆的 .jsonl）嗎？
不行，整份輸入會被當成單一 JSON 值來解析，多行各自獨立的 JSON 會在第二行就報錯。請一次貼一行，或改用支援 JSON Lines 的工具。