Data & Formats

JSON Diff Tool

Paste two JSON documents into the left and right editors, and DevKitLab shows you a git-style side-by-side or unified diff together with a structural change list keyed by JSON Path. When a string value differs in a long way, the changes panel automatically expands a word-level red / green highlight so you can see exactly which fragment changed — no need to hand-diff a long string. You can ignore key order for semantic comparison, collapse unchanged sections to focus on the diff, jump between changes, and reformat both sides with one click. Everything runs locally in your browser, so both payloads stay on your device.

  • Side-by-side git-style diff with whole-line highlighting plus character-level outlines for inline changes
  • Switch to unified mode to see inline old / new fragments without two columns
  • Structural change panel keyed by JSON Path lists every add / remove / modify / move; click to jump to the editor
  • Long string changes expand into a word-level red / green diff so you can pinpoint the exact difference
  • Optional key-order-insensitive semantic comparison, so reordered keys do not look like a full rewrite
  • Collapse unchanged sections (on by default) to focus on diff context only — usable even on huge JSON
  • Previous / next change shortcuts, swap sides, and a one-click reformat for both sides
  • Array elements aligned by id / key / name / uuid / _id heuristic, so inserting one item does not shift the rest
  • Left and right inputs auto-save to localStorage and survive a refresh
  • Fully local processing: both payloads, tokens, configs, and logs are not uploaded to a server
tools/JSON Diff
Original JSON
Modified JSON
Paste JSON on both sides to start comparing
Paste JSON on both sides to start comparing
Diff commands

Overview

This JSON diff goes beyond putting two payloads side by side. It gives you both a text view and a semantic structural view, plus character-level highlighting, word-level long-string diffs, path jumping, and array alignment — so reviewing API changes, config edits, and fixture deltas is faster and less error-prone.

  1. 01

    Side-by-side git-style diff

    Two CodeMirror editors with synchronized scrolling. Changed lines are highlighted, and within each changed line, character-level outlines mark the exact substring that changed — similar to a GitHub PR diff.

  2. 02

    Unified inline mode

    A single editor view with the previous text shown as a read-only overlay above each change block. Small edits are displayed inline so you can read the old and new fragments together.

  3. 03

    Structural change list

    A right-hand panel lists every change keyed by JSON Path like $.users[2].name. Add / remove / modify / move each have a distinct color and icon, so the type of change is obvious at a glance.

  4. 04

    Word-level diff for long strings

    When a string field differs in a long way, the change row expands a word-level red / green highlight showing exactly which fragment was rewritten, inserted, or removed — no second tool required for long-string review.

  5. 05

    Key-order-insensitive comparison

    Toggle Ignore key order to make the structural diff sort keys recursively before comparing. Combine with Format both to also rewrite the editor contents so the visual diff ignores key order too.

  6. 06

    Collapse unchanged sections

    On by default. Long stretches of identical content collapse, keeping three lines of context around each change. Even configs with thousands of unchanged lines stay readable.

  7. 07

    Navigate between changes

    Previous / next buttons jump chunk by chunk through the diff. Combined with the JSON Path panel, no change is overlooked in a long review.

  8. 08

    Array alignment by content

    By default, array elements are matched by id / key / name / uuid / _id, avoiding the common diff noise where inserting one item makes the entire tail look changed.

  9. 09

    One-click format both sides

    When the two sides differ only in indentation or key order, Format both rewrites both editors with 2-space indentation (and sorts keys if Ignore key order is on), so the visual diff becomes clean instantly.

  10. 10

    Fully local, no upload required

    Parsing, diffing, string-level diff, copying, and file reading all happen in the browser. Both payloads — production responses, tokens, configs — stay on your device.

How to use

The usual flow: paste both sides, optionally enable Ignore key order and Format both, then review with the split view plus the structural panel, and copy paths for anything you need to flag.

  1. 01

    Paste the original JSON into the left editor and the modified JSON into the right. Both are editable, and inputs auto-save to localStorage.

  2. 02

    The default split view shows whole-line red / green highlighting with character-level outlines for inline changes. Switch to unified view if you prefer one column.

  3. 03

    Read the Structural changes panel on the right. Every change is keyed by JSON Path; click a row to jump to the matching position in the editor.

  4. 04

    If a string field differs and both sides are long, the row expands a word-level diff that pinpoints the changed fragment.

  5. 05

    If reordered keys make the visual diff noisy, enable Ignore key order and click Format both — the visual diff becomes clean immediately.

  6. 06

    Use Previous / Next to step through changes chunk by chunk. The default collapse-unchanged keeps the surrounding context short; turn it off when you want the full document.

  7. 07

    When you need to reference a field in docs or a ticket, hover a row in the panel and click the copy icon to grab a precise path like $.data.users[0].email.

Details

These features address the most common JSON diff problems: line diff hides character-level changes, long strings hide where the difference is, reordered keys look like full rewrites, an inserted array item shifts everything, and giant payloads are hard to review end to end.

  • Side-by-side git-style split view, with whole-line highlighting and character-level outlines for inline edits.
  • Unified inline mode with the previous text shown as a read-only overlay above each change block.
  • Structural change panel keyed by JSON Path, with distinct colors for add / remove / modify / move.
  • Long-string changes automatically expand into a word-level red / green diff inside the panel.
  • Toggle Ignore key order so reordered keys do not look like a full rewrite at the structural level.
  • Toggle Collapse unchanged to focus on diff context only and skip large unchanged stretches.
  • Previous / next buttons jump chunk by chunk so nothing is missed in a long review.
  • Array elements aligned by id / key / name / uuid / _id heuristic to avoid shift noise.
  • One-click Format both to align indentation across the two editors, plus key sorting when configured.
  • Swap mirrors the two sides; Clear resets both. Inputs persist to localStorage.
  • Theme follows the system, with red / green palettes calibrated for both light and dark mode.

Use cases

Use this tool whenever you have two JSON documents and need to know exactly what differs between them.

  1. Review API response changes

    Paste the previous and current responses for an endpoint and immediately see which fields were added, removed, or changed — including nested structures and long string fields.

  2. Config file diff

    Review tsconfig, package.json, ESLint config, CDN rules, and feature flag changes. With Ignore key order on, reordered keys do not pollute the actual semantic diff.

  3. Fixture and seed-data regression checks

    Compare the old and new versions of a test fixture to confirm that your change only touched the expected fields and did not accidentally affect other cases.

  4. JWT or token payload comparison

    Decode two JWTs, paste their payloads here, and compare claims to verify issuer, audience, scope, and other fields against expectations.

  5. AI tool-call argument review

    Compare the arguments of two tool calls in a session or successive snapshots of an agent state to find which step introduced an unexpected change.

  6. Webhook replay validation

    Compare a captured production webhook with a payload produced in replay to confirm that everything except the signature matches exactly.

  7. Cross-environment config audit

    Diff dev / staging / prod config JSON to find which keys differ between environments, then align them around a baseline.

  8. Pre- and post-migration data comparison

    After a data migration, bulk rename, or refactor, paste before / after samples to confirm the structural change matches expectations and no value field was accidentally overwritten.

  9. Incident postmortems

    Compare the payload at the time of the incident with a known-good payload. The word-level long-string diff makes it easy to find exactly which encoding or value triggered the downstream failure.

See also

Want to clean up each side before comparing? Send them through JSON Formatter first to validate syntax, run smart repair, and unify formatting, then come back here. To convert any differing fragment into another format afterwards, hand it to JSON Converter . If the two payloads are wrapped in log prefixes or other text, strip the outer wrappers with Text Replace before pasting them here so you can compare the real payloads.

Understanding what different means here

JSON diff sounds simple, but text diff and structural diff give different answers. These concepts come up frequently during reviews.

  1. Text diff vs semantic diff

    The red / green highlighting in the two editors is a text diff that treats whitespace, key order, and indentation as changes. The structural panel on the right is a semantic diff that only cares about actual field and value changes. Use them together.

  2. Key order is not meaningful in strict JSON

    {"a":1,"b":2} and {"b":2,"a":1} are semantically identical but textually different. With Ignore key order on, the structural diff treats them as the same. To make the visual diff match, click Format both.

  3. Array alignment drives diff noise

    Inserting an item in the middle of an array would, under positional comparison, mark every following element as changed. Here, array elements are matched by id / key / name / uuid by default to avoid this false-positive noise.

  4. Long string values need word-level diff

    For long string fields (descriptions, prompts, URLs, HTML fragments), marking the whole field as changed is not useful. The panel automatically expands a word-level red / green diff so you can see exactly which fragment differs.

  5. Move vs modify

    When an array element moves from one position to another, jsondiffpatch reports it as moved rather than removed + added. That information helps you tell reordering apart from actual content changes.

  6. JSON Path is the precise way to refer to a field

    Every row in the panel shows a path like $.users[2].name. Copy it into docs, tickets, or comments — much clearer than the user’s name field.

Best practices

Config diffs, API change reviews, and fixture comparisons all benefit from a steady review routine, especially as payloads grow. These habits reduce misreads.

  • Read the top-of-panel summary first (X added · Y removed · Z modified) to gauge the size of the change before diving in.
  • When you see a sea of red and green, first check whether reordered keys or indentation are the cause. Enable Ignore key order and click Format both before judging real semantic change.
  • For arrays where elements lack an id-like field, the default alignment falls back to positional matching. Add a stable field to your sample data if you need cleaner array diffs.
  • When a string field shows a whole-string change, expand the word-level diff first before moving to a dedicated text diff tool.
  • During long reviews, keep Collapse unchanged on and use Previous / Next to step through changes chunk by chunk to avoid missing anything.
  • When flagging a change in a doc or ticket, copy the JSON Path from the structural panel — far more precise than describing the field in prose.
  • Redact production data before sharing. The tool does not upload anything, but anything you screenshot or paste into tickets and chats can leak.

Limitations

This tool focuses on showing you the difference between two JSON documents. It does not replace schema validation, change-management workflows, or proper version control.

  • It tells you what differs, not whether the difference is acceptable. Business rules, version constraints, and backward-compatibility checks still belong in schemas, code review, and regression tests.
  • It is not Git. There is no commit history, branches, or blame — only a two-way comparison between two static payloads. Use a version control system to track long-term evolution.
  • Word-level long-string diff splits on word boundaries, which is less effective for languages without spaces such as Chinese or Japanese. Use it alongside the editor’s character-level outlines for those.
  • Array alignment uses id / key / name / uuid heuristics. If your elements lack stable identifiers and order matters, results may fall back to positional matching and show shift noise.
  • Very large payloads in the tens of megabytes may slow down the browser, especially the structural diff. Extract the relevant subtree or use command-line diff tools instead.
  • All processing is local, but local safety still depends on your device, browser extensions, screen sharing, and what you copy elsewhere.

FAQ

Common questions about structural diff, long-string diff, key order, array alignment, privacy, and large payloads.

Will my JSON be uploaded to a server?

No. Parsing, diffing, string-level diff, copying, and file reading all happen in the current browser tab. DevKitLab does not send your payload to a server.

Why does the editor highlighting sometimes disagree with the structural panel?

The editor highlighting is a text diff and is affected by whitespace, key order, and indentation. The structural panel is a semantic diff and only cares about real field and value changes. With Ignore key order on and Format both applied, the two usually line up.

What exactly does Ignore key order do?

It recursively sorts object keys before computing the structural diff. So {"a":1,"b":2} and {"b":2,"a":1} are not treated as different. Note it only affects the structural panel, not the editor — click Format both to make the visual diff ignore key order as well.

Why did inserting an array item not mark everything after it as changed?

Array elements are matched by id / key / name / uuid / _id by default, so the tool can recognise which element moved where. If your elements lack those fields, the comparison falls back to positional matching, and inserting an item will indeed shift the rest.

A long string field shows as changed but I cannot see where the difference is.

The structural panel automatically expands a word-level red / green diff under long-string changes — removed words in red, added words in green. For very long strings (over 20k characters) the view falls back to whole-string red / green to stay responsive.

Does Collapse unchanged hide any of the diff?

No. It only collapses long stretches of identical content, keeping three lines of context around each change. Click the collapsed bar to expand a section temporarily, or turn the option off to see the full document.

My two sides have different formatting (one indented, one not). Is the diff going to be a sea of red?

Yes, because the editor does a text diff. Click Format both to unify indentation first. The structural panel is unaffected since it compares semantically.

At what granularity do Previous / next jump?

They jump between diff chunks (contiguous change blocks), not between rows in the structural panel. One chunk may contain several structural changes, and one field change may span multiple chunks.

Why am I seeing a moved entry?

When an array element moves to a different position with the same content, the tool labels it as moved instead of removed + added. This helps you tell reordering apart from real content changes.

Do my left and right editors survive a refresh?

Yes. Both inputs auto-save to localStorage and restore on next visit. Clear wipes both the editor contents and the saved cache.

Can it handle very large JSON files?

Payloads of a few megabytes generally work well. Tens of megabytes may slow the browser, especially the structural diff. Consider extracting the relevant subtree or using command-line diff tools.

Does it support three-way diff (base / left / right)?

Only two-way comparison for now. For three-way merges, use Git’s merge tools or an IDE’s built-in diff viewer.

Related tools

Continue your JSON workflow with the data tools: format, convert to other formats, or strip outer text wrappers.