JSON Swiss

JSON Swiss

JSON Diff and Compare Tool

A: JSON A
B: JSON B
1
1

オンラインで JSON を比較する方法 – ステップバイステップガイド

1ステップ 1 – 2 つの JSON を貼り付ける／インポートする2ステップ 2 – 比較オプションを設定する3ステップ 3 – diff の可視化を確認する4ステップ 4 – 結果をエクスポートする

このオンライン JSON 比較ツールで 2 つの JSON を左右に並べて確認し、差分をハイライトして、バージョン管理や 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 – 2 つの 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.

    • 1 つ目の JSON を左のエディター（JSON A）に、2 つ目を右のエディター（JSON B）に貼り付けます。
    • または、各サイドでインポートを使い、ファイル／URL／クリップボードから JSON を読み込みます。
    • 実際の 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 – diff の可視化を確認する

    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 を整形

先に整形して空白を正規化し、diff を読みやすくします。

スキーマ生成

JSON から JSON Schema を生成し、将来の変更を期待する構造に対して検証します。

JSON → TypeScript

JSON から TypeScript 型を生成し、型安全に変更を追跡します。

JSONを表に変換

比較した JSON をインタラクティブなテーブルエディターで編集できます。

よくある質問

JSON の比較はどのように動作しますか？

このツールは構造的な diff を行い、ネストされたオブジェクトや配列の追加・削除・変更を検出します。

JSON データはアップロードされますか？

いいえ。すべてブラウザ内でローカルに処理され、サーバーへアップロードされることはありません。

利用できる比較オプションは何ですか？

空白、大小文字、順序を無視して、フォーマットの違いではなく重要な構造変更に集中できます。

空白を無視できますか？

はい。このオプションは文字列値内の空白を正規化します。文字列の外側の空白は JSON の解析時に既に無視されます。

大小文字を無視できますか？

はい。大文字/小文字を無視を有効にすると、キーと文字列値を大小文字を区別せずに比較します。

順序を無視できますか？

はい。順序を無視を有効にすると、オブジェクトのキーや配列要素の順序を重要視しない比較になり、順序が意味を持たない場合に便利です。

エディターが時々読み取り専用になるのはなぜですか？

いずれかの無視オプションを有効にすると、ハイライトがルールと一致するよう正規化プレビューに切り替わるため読み取り専用になります。オプションをオフにして生の JSON を編集してください。

JSON Patch（RFC 6902）とは何ですか？

JSON Patch は、1 つの JSON ドキュメントを別の JSON に変換するための標準操作（add/remove/replace など）のリストです。

エクスポートされる JSON Patch はどのように生成されますか？

JSON Pointer パスに基づき、A → B のための信頼できる操作セットを計算します。配列ではインデックスずれを避けるため、保守的な置換を行う場合があります。

結果をエクスポートまたは共有するには？

概要をコピーで簡単な要約をコピーし、レポートをエクスポートで Markdown レポートをダウンロード、または JSON Patch をエクスポートで変更をプログラム的に適用できます。