驗證 JSON 檔案的意思是，將其文字內容透過一個嚴格的解析器執行，檢查它是否符合 RFC 8259 所定義的語法——這是 IETF 為 JSON 資料交換格式制定的規範。當檔案中的每個鍵與字串都以雙引號包裹、方括號與大括號成對匹配，而且沒有註解、尾端逗號、或解析器預期之外、無法表示的值（例如 NaN）時，該檔案即通過驗證。判定結果是二元的：JSON 要麼能被標準解析器解析，要麼不能；而當這個二元答案附帶解析失敗時的精確行列位置時，實用價值便大幅提升。一個具備位置資訊的驗證工具，能將模糊的「unexpected token」抱怨，轉換成你可在編輯器中直接跳轉的座標。針對這種聚焦於語法優先的檢查，免費的 JSON Validator 會執行瀏覽器內建的原生 JSON 解析器，並回傳綠色的「Valid JSON」判定，或是一則紅色訊息，指出失敗所在的行列位置。
JSON 驗證工具實際檢查的內容
JSON 由 RFC 8259 定義，並沿用 ECMA-404 的語法，而該語法定義上是相當嚴格的。驗證工具本質上就是一個解析器，它會嘗試將你的文字讀取為一個完整的 JSON 值——物件、陣列、字串、數字、true、false 或 null——並在無法對齊的第一個 token 處成功或停止。最常見的拒絕情況來自於看似可選、實際上卻不是的規則：
- 物件鍵必須以雙引號包裹；未加引號或使用單引號的鍵會被拒絕。
- 字串值同樣必須使用雙引號，絕不能使用單引號，且每個控制字元都必須進行跳脫。
- 陣列或物件最後一個元素之後不允許尾端逗號。
- 任何形式的註解，包括 // 與 /* */，都不屬於 JSON 語法的一部分。
- NaN、Infinity 與 -Infinity 並非有效的 JSON 數字。
- 每個開啟的方括號、大括號與引號，都必須依正確順序關閉。
由於這些規則與每個標準解析器強制執行的規則一致，驗證工具的語法通過結果，會與你的 JavaScript 執行環境、Node.js，以及大多數 JSON 函式庫在生產環境中所接受的內容相符。這裡沒有寬鬆的猜測，也沒有自動修復——判定結果精確反映你的下游程式碼將套用的語法。
破壞 JSON 檔案的常見語法錯誤
大多數「invalid JSON」報告都來自少數幾種反覆出現的錯誤。下表將每種模式與其違反的規則，以及解析器將產生的錯誤訊息類型配對呈現。
| 檔案內容 | RFC 8259 的要求 | 典型的解析器訊息 |
|---|---|---|
| { name: "Alice" } | 物件鍵必須使用雙引號。 | Unexpected token n |
| { 'name': 'Alice' } | 字串與鍵僅能使用雙引號。 | Unexpected token ' |
| [1, 2, 3,] | 陣列最後一個元素之後不得有尾端逗號。 | Unexpected comma in array |
| // a note | 註解不屬於 JSON 的一部分。 | Unexpected token / |
| {"x": NaN} | 僅允許有限的十進位數字。 | Unexpected token N |
| {"a": 1 | 每個開啟的大括號都必須有對應的關閉大括號。 | Unexpected end of JSON input |
這六種模式佔了大多數的驗證失敗情況。用肉眼辨識它們能加速除錯；當你無法辨識時，驗證工具所提供的行列錯誤訊息便會代勞。
如何在瀏覽器中驗證 JSON 檔案
這個驗證工具的設計目的是快速且精準地回答一個問題：這個 JSON 是否真的有效？如果無效，具體是在哪裡斷裂？大多數工作流程可分為三個步驟。
- 將你的 JSON 貼上或輸入到輸入框中。檔案內容僅停留在頁面內——不會上傳至任何遠端服務。
- 立即讀取判定結果。綠色的「Valid JSON」訊息代表文字解析無誤。紅色訊息則會回報解析器放棄的行列位置，例如「Invalid JSON at line 3, column 7.」。
- 對於有效的 JSON，請檢視結構報告。驗證工具會顯示頂層類型、最大巢狀深度、總鍵數、物件與陣列數量，以及字元數，協助你對資料結構進行健全性檢查。
典型的工作流程為：貼上、讀取判定、修正、重複此步驟，直到檔案解析無誤。由於驗證工具僅專注於正確性與結構診斷，它刻意保持你的文字不變——若你需要美化輸出或壓縮為單行，則屬於另一項獨立任務，可交由像 JSON Formatter 這類工具處理。
解讀結構報告
綠色的判定結果告訴你檔案可以解析，但無法告訴你該檔案是否符合你的程式碼所預期的結構。結構報告透過五個值得一覽的數字，彌補了這項落差：
- 頂層類型——物件、陣列、字串、數字、布林值或 null。這是確認你貼上的是正確檔案的最快速檢查。
- 最大巢狀深度——檔案中陣列或物件最深層的層級。有助於察覺意外發生的失控巢狀。
- 總鍵數——每個巢狀物件中鍵的總和。數值突然飆升，通常意味著資料集重複或膨脹。
- 物件與陣列數量——檔案中各自包含的容器數量。
- 字元數——檔案的精確長度，在監控酬載大小時相當實用。
在多數除錯過程中，深度與鍵數是真正能抓到問題的兩個數值：一個回應的深度若從 4 躍升至 14，或鍵數以一個數量級的幅度暴增，通常代表你開啟了錯誤的端點，或是不小心重複了某個段落。
為何在本機瀏覽器驗證檔案至關重要
JSON 檔案經常包含你不太願意分享給遠端服務的內容——API token、工作階段 cookie、客戶記錄、內部組態設定。JSON Validator 完全在瀏覽器內執行，使用引擎內建的 JSON.parse，因此檔案內容絕不會離開你的裝置。這使得它適合用於驗證生產環境的酬載、匯出的使用者資料，或是你不會貼上雲端工具的預備環境背後的組態檔。
當你正在除錯從日誌封存檔或同事的分支中抽出的單一可疑檔案時，這項特性同樣有所助助。你可以貼上它、讀取判定、在編輯器中修正、再次貼上，並在過程中完全不需要任何網路往返。若經過驗證的檔案最終需要以更小、單行的產出形式發布，你可以在驗證後將其交給本機的壓縮工具；該工作流程的逐步說明，記載於這份在瀏覽器中壓縮 JSON 檔案的指南中。
JSON 驗證的限制與注意事項
語法有效性是一項二元且範圍狹窄的檢查，了解其適用邊界相當重要。實務上有三項注意事項值得留意：
- 極大的整數會喪失精度。JSON 數字會以 IEEE-754 雙精度浮點數讀取，這種格式僅能精確表示至 2^53 的整數。驗證「通過」僅代表數字本身解析無誤，並不保證 19 位數的 id 能完整保留。
- 結構描述有效性是另一個問題。語法有效性代表檔案可解析；結構描述有效性則代表解析後的值符合預期的結構。若你的下游程式碼預期某個物件帶有特定欄位，語法檢查並不會抓出漏失的欄位。
- 深層巢狀的檔案會被回報，而非導致當機。病態的巢狀結構會被攔截並顯示出來，而非放任它拖垮瀏覽器，因此即使面對惡意輸入，你也能始終獲得判定結果。
驗證工具的判定奠基於與生產環境解析器相同的 RFC 8259 語法，因此當它表示檔案有效時，這與你在 Node 的 JSON.parse、Python 的 json 模組，以及命令列的 jq 中得到的答案一致。若你想確切了解哪些 token 被接受、哪些不被接受，值得一讀完整規範——它以 RFC 8259: The JSON Data Interchange Format 為名公開發布。