這個工具在做什麼

JSON（JavaScript Object Notation）是目前 API 傳輸資料最普遍的格式。它的規則很嚴格，少一個引號、多一個逗號就整份解析失敗，而伺服器回傳的錯誤訊息又常常只有一句「Invalid JSON」，不告訴你錯在哪裡。

這個工具做三件事：把壓縮過的 JSON 攤開成人看得懂的排版、把排版過的 JSON 壓回單行以節省傳輸量，以及在語法錯誤時直接指出第幾行第幾個字元出錯並顯示前後文，讓你不必逐字比對。

JSON 最常見的五個語法錯誤

這五種佔了實務上絕大多數的解析失敗，而且都是「看起來很合理但標準不允許」：

最後一個元素後面多一個逗號。JavaScript 的物件實字允許，但 JSON 標準不允許。

{ "a": 1, "b": 2, }     ← 錯誤
{ "a": 1, "b": 2 }      ← 正確

JSON 規定字串一律用雙引號，鍵名也必須加雙引號。

{ 'name': 'Joel' }      ← 錯誤
{ name: "Joel" }        ← 錯誤（鍵名沒加引號）
{ "name": "Joel" }      ← 正確

JSON 標準沒有註解語法，// 和 /* */ 都會導致解析失敗。需要註解時，可考慮改用 JSON5、JSONC 等擴充格式，或另外加一個 _comment 欄位。

undefined、NaN、Infinity 都不是合法的 JSON 值。JSON 只認得字串、數字、true、false、null、陣列與物件這七種。

雙引號、反斜線與換行必須跳脫，寫成 \"、\\、\n。Windows 路徑特別容易踩到：

{ "path": "C:\Users\Joel" }      ← 錯誤
{ "path": "C:\\Users\\Joel" }    ← 正確

這個問題不會讓解析失敗，反而更危險——它會安靜地改掉你的資料。

JavaScript 的數字採 IEEE 754 雙精度浮點數，能精確表示的整數上限是 9007199254740991（約 9×10¹⁵，即 16 位數）。超過這個範圍的整數在解析後會被四捨五入：

JSON.parse('{"id": 12345678901234567890}')
// 得到 { id: 12345678901234567000 }  ← 末幾位變了

雪球式 ID（如 Twitter/Discord 的 snowflake ID）、訂單編號、身分證字號轉成的數字都可能中招。解法是在 API 端就把這類欄位當成字串傳輸，而不是數字。本工具在偵測到超長整數時會提出警告。

情境	建議	原因
API 回應、網路傳輸	壓縮成單行	縮排空白可佔總大小的 10～30%，累積起來相當可觀
設定檔、需要人工維護	格式化（2 空格）	可讀性優先；2 空格是 JavaScript 生態最常見的慣例
納入版本控制	格式化 + 鍵值排序	每個值獨立成行，diff 才看得出真正改了什麼；排序可避免鍵順序變動造成的假差異
除錯、閱讀他人的 API	格式化（4 空格）	巢狀層級較深時，縮排大一點比較看得出結構

順帶一提，實務上 gzip 壓縮會把大部分重複的空白吃掉，所以若你的伺服器已啟用 gzip 或 Brotli，壓縮 JSON 帶來的頻寬節省會比想像中小。但對於不經壓縮的場景（例如寫入資料庫欄位、訊息佇列的 payload），差別就很明顯。

有時你需要把一整份 JSON 塞進另一份 JSON 的某個欄位裡，或寫進程式碼的字串常數中，這時所有的雙引號都得跳脫。手動改很容易漏，用「跳脫為字串」一鍵完成：

原始： {"a":1}
跳脫： "{\"a\":1}"

反過來，當你從 log 裡撈到一段被跳脫過的 JSON 字串，用「反跳脫」就能還原成正常的 JSON 再進行格式化。

這個工具完全在你的瀏覽器中執行，沒有任何後端伺服器參與。你貼上的內容不會被傳送、記錄或分析，關閉分頁後就消失。因此即使 JSON 中含有 API 金鑰、個人資料或未公開的商業資訊，也可以安心使用。詳細說明請見隱私權政策。