JSON Swiss 標誌

JSON Swiss

JSON Diff and Compare Tool

A：JSON A
B：JSON B
1
1

Best-fit scenarios

API response comparison

Compare JSON responses from v1 and v2 endpoints to confirm added fields, removed fields, and value changes during integration or regression testing.

Configuration drift review

Compare development, staging, and production JSON config files while using ignore-order rules to reduce irrelevant noise.

Data migration validation

Check old and new JSON structures after migration work so renamed fields, default values, and split objects are easy to verify.

Log and snapshot comparison

Compare two requests, logs, or state snapshots to understand exactly what changed before and after an issue appeared.

Two JSON file diff

Import or paste two JSON files and inspect structural and field-level differences for configs, exports, fixtures, or API samples.

如何線上比對 JSON 檔案 – 分步指南

1步驟 1 – 貼上或匯入兩份 JSON2步驟 2 – 設定比對選項3步驟 3 – 查看差異視覺化4步驟 4 – 匯出結果

使用此線上 JSON 比對工具，可左右對照查看兩個 JSON，將差異高亮，並匯出 Patch 或報告，適用於版本比對與 API 測試。

Understand version drift before acting on it

The compare tool helps answer what changed, not just whether the text looks different

In most workflows, you care about whether fields were added, removed, or changed in meaning, not whether two files differ by whitespace or order. That is why a structural JSON compare is more useful than plain text diff.

JSON A (older version)
1
{
2
"id": 1,
3
"name": "Maeve",
4
"status": "active",
5
"roles": ["admin", "editor"]
6
}
JSON B (newer version)
1
{
2
"id": 1,
3
"name": "Maeve Winters",
4
"status": "active",
5
"roles": ["admin", "editor"],
6
"email": "[email protected]"
7
}

If you only need the high-level answer first, read the summary. If you need exact field-level context, stay in the diff view.

3 compare examples that reflect real work

These examples mirror the most common JSON diff workflows in development, QA, and operations: API upgrades, environment config review, and data migration verification.

API Versioning

Compare API response v1 and v2 to confirm added fields

This is ideal when frontend and backend teams need to verify exactly what changed between response versions.

Response v1
1
{
2
"user": {
3
"id": 42,
4
"name": "Maeve"
5
},
6
"status": "active"
7
}
Response v2
1
{
2
"user": {
3
"id": 42,
4
"name": "Maeve"
5
},
6
"status": "active",
7
"profile": {
8
"email": "[email protected]"
9
}
10
}

This kind of diff is especially useful when you need to verify added fields before updating tests or frontend models.

Environment Config

Remove ordering noise so the real config differences stand out

When object keys or array members are semantically unordered, selective ignore rules can reduce a lot of useless diff noise.

Staging
1
{
2
"features": ["coupon", "betaCheckout"],
3
"retry": 2,
4
"timeout": 5000
5
}
Production
1
{
2
"features": ["betaCheckout", "coupon"],
3
"retry": 3,
4
"timeout": 5000
5
}

With ignore order enabled, the important change becomes obvious: retry changed, while the feature list did not meaningfully drift.

Migration Review

Check data migration output and export a Patch for automation

This works well when old structures are being split, renamed, or normalized into a new shape.

Before migration
1
{
2
"fullName": "Maeve Winters",
3
"active": true
4
}
After migration
1
{
2
"firstName": "Maeve",
3
"lastName": "Winters",
4
"status": "active"
5
}

If the migration pipeline needs repeatable change application, exporting both the Markdown report and JSON Patch is often worthwhile.

  1. 01

    Tutorial Step

    步驟 1 – 貼上或匯入兩份 JSON

    Before you look at the diff, be clear about what each side represents: old versus new, staging versus production, previous response versus current response. That mental model makes the later change review much easier.

    • 將第一份 JSON 貼到左側編輯器（JSON A），第二份貼到右側編輯器（JSON B）。
    • 也可使用「匯入」從檔案、URL 或剪貼簿分別載入兩側內容。
    • 建議使用真實 API 回應、設定檔或資料匯出，以比對實際變更。
    • Try to compare payloads from the same business scope or time window so you do not mix unrelated changes into one review.
    • Check the imported names or source labels before reviewing the diff so you do not accidentally reverse the sides.
  2. 02

    Tutorial Step

    步驟 2 – 設定比對選項

    Ignore whitespace, case, and order are useful only when they match the meaning of your data. The fastest approach is to choose them intentionally instead of enabling every option by default.

    • 開啟「忽略空白」，聚焦結構而非格式。
    • 開啟「忽略大小寫」，以不區分大小寫的方式比對鍵名與字串值。
    • 當順序不應算作變更時，開啟「忽略順序」。
    • When any ignore rule is enabled, the page switches to a normalized preview so the highlights match the actual comparison logic.
    • If you are unsure whether order matters, review the raw diff first and turn on ignore order only after you confirm the noise pattern.
  3. 03

    Tutorial Step

    步驟 3 – 查看差異視覺化

    A useful comparison is more than colored highlights. The best signal usually comes from combining three things: the field-level diff, the change counts in the status area, and the high-level summary you can copy or export.

    • 左右對照檢視會標出新增（綠）、刪除（紅）與修改（黃）。
    • 在狀態列查看變更數量與分類統計。
    • 依螢幕大小或使用習慣，在「對照/合併」檢視間切換。
    • Copy Summary is useful when you need to explain the result quickly in a ticket, chat, or review thread.
    • If the diff suddenly looks much larger than expected, confirm that the two payloads actually come from the same source scope before digging deeper.
  4. 04

    Tutorial Step

    步驟 4 – 匯出結果

    This page does not just show differences. It can produce three useful outputs depending on what happens next: summary text for communication, Markdown reports for documentation, and JSON Patch for automation.

    • 複製摘要，方便在聊天、工單或文件中快速分享。
    • 匯出 Markdown 報告，包含詳細變更與統計資訊。
    • 匯出 JSON Patch（RFC 6902），用於程式化套用變更。
    • For config comparisons, keep the report with version identifiers so rollback and audit are easier later.
    • If one of the payloads still needs field-by-field review, move it into the table editor after the comparison step.

A more reliable compare workflow

1

Validate both payloads first so broken JSON does not pollute the diff.

2

Review the raw comparison once before enabling ignore rules so you understand what noise is present.

3

Use the diff highlights, counts, and summary together to judge the scale and type of change.

4

Use summary text for communication, Markdown reports for records, and JSON Patch for automation.

5

If one side still needs field-level inspection or editing, continue into the formatter or table editor after comparison.

The compare page is best used to answer not whether two files look different, but where the JSON structure and meaning actually changed.

JSON 比對小技巧

先驗證兩份 JSON，避免語法錯誤掩蓋真實差異。
比對 API 回應時，可考慮開啟「忽略順序」，減少因陣列順序變動造成的雜訊。
需要可機器讀取的差異時，使用 JSON Patch 匯出以利環境同步。
If the diff is hard to read, format both payloads first, then compare again.

相關 JSON 比對與 Diff 工具

將這些工具與 JSON 比對搭配使用，可完成驗證、格式化與程式碼產生等工作流。

格式化 JSON

先格式化以統一空白與結構，讓差異更易閱讀。

驗證 JSON

比對前先驗證兩份 JSON，確保語法正確。

修復 JSON

pages.compare.related.repairCardDescription

JSON 轉 Excel

pages.compare.related.jsonToExcelCardDescription

常見問題

JSON 比對是如何運作的？

本工具會進行結構化差異分析，可在任意巢狀層級識別新增、刪除與修改。

會上傳我的 JSON 資料嗎？

不會。所有處理都在瀏覽器本機完成，資料不會上傳到伺服器。

有哪些比對選項？

你可以選擇忽略空白、忽略大小寫、忽略順序，以便聚焦在真正的結構變化，而非格式差異。

可以忽略空白嗎？

可以。忽略空白會對字串值內部的空白進行標準化；字串之外的空白在 JSON 解析時本就會被忽略。

可以忽略大小寫嗎？

可以。啟用後會以不區分大小寫的方式比對鍵名與字串值，減少無意義差異。

可以忽略順序嗎？

可以。啟用後會把物件鍵與陣列元素視為順序不敏感，更適合順序不重要的清單。

為什麼編輯器有時是唯讀的？

當啟用任一忽略選項時，檢視會切換到標準化預覽，確保高亮與規則一致，因此會變為唯讀。關閉選項即可回到可編輯的原始檢視。

什麼是 JSON Patch（RFC 6902）？

JSON Patch 是一組標準操作（add/remove/replace 等），用於把一個 JSON 文件轉換為另一個。

匯出的 JSON Patch 如何產生？

我們基於 JSON Pointer 路徑計算 A → B 的可靠操作集合；對於陣列，為避免索引漂移，可能採用較保守的替換策略。

如何匯出或分享比對結果？

點擊「複製摘要」可快速複製概覽；「匯出報告」可下載 Markdown 報告；「匯出 JSON Patch」可用於程式化套用變更。