Compare JSON as normalized, readable text

A useful JSON diff must separate real data changes from formatting noise. This JSON compare tool parses an original document and a modified document, pretty-prints each with two-space indentation, then aligns their lines. By default it also sorts object keys recursively so property-order differences do not dominate the result. Arrays retain their original order because moving an array item can change meaning.

The editors and diff viewer are separate tabs. Validation happens as either input changes, but the Diff Viewer becomes available only when both sides contain valid JSON. Once there, choose a side-by-side table for direct alignment or a unified stream for a patch-like reading experience.

Establish the comparison

Enter the baseline in Original JSON (Left).
Enter the candidate in Modified JSON (Right).
Leave Sort keys alphabetically enabled when object property order is irrelevant. Disable it when serialized order itself is what you need to inspect.
Open Diff Viewer after both editors validate.
Review red removed lines and green added lines. Unchanged lines retain their original line numbers in the normalized documents.

There is no Compare button to press. The aligned result is recalculated whenever an input or the key-sorting option changes. Each editor has its own copy action, which copies the original text from that side, not the normalized diff representation. Clear resets both inputs, errors, rows, and the active tab. Load Sample fills both sides and opens the diff immediately.

What normalization means here

Both documents pass through JSON.parse and JSON.stringify(value, null, 2). Original indentation, compactness, blank lines, and spacing therefore do not create differences. Number and escape spellings may be normalized during this process.

With sorting enabled, every object’s keys are arranged alphabetically, including objects nested in arrays. Array elements themselves are mapped in place and never sorted. Consider these values:

{"region":"us-east-1","limits":{"workers":4,"jobs":20}}

{
  "limits": { "jobs": 20, "workers": 4 },
  "region": "us-east-1"
}

They produce the same normalized text when sorting is enabled. With sorting disabled, property order can appear as removed and added lines even though ordinary JSON consumers typically treat object order as insignificant.

Key sorting is recursive but not canonicalization. It uses JavaScript’s default string sorting and does not implement a formal canonical JSON specification. Duplicate keys are already resolved by parsing, and very large integers are subject to JavaScript number precision.

Reading a changed object

Suppose the original service settings are:

{
  "service": "billing",
  "enabled": true,
  "retry": { "attempts": 2, "delayMs": 500 },
  "regions": ["us", "eu"]
}

The modified settings are:

{
  "service": "billing",
  "enabled": false,
  "retry": { "attempts": 3, "delayMs": 500 },
  "regions": ["us", "apac", "eu"],
  "owner": "payments-platform"
}

The line-based diff shows old value lines as removals and new value lines as additions. A value modification is therefore represented by a red line followed or aligned with a green line; there is no separate “modified” row type and no character-level highlight inside the line. The new owner property and "apac" array item also appear as additions.

This distinction matters when interpreting braces or commas. Because the comparison operates on pretty-printed lines, punctuation can move alongside a nearby structural change. Read the surrounding unchanged lines to understand the actual object or array affected.

Side-by-side versus unified view

Side-by-Side displays original line numbers and content on the left, modified line numbers and content on the right. Blank patterned cells represent a line that exists only on the other side. This view is effective when values remain near the same location and horizontal screen space is available.

Unified uses two line-number columns followed by one content column. A minus prefix marks an original-only line, and a plus prefix marks a modified-only line. Unchanged content has both line numbers. It is easier to follow on a narrower display and resembles familiar version-control output.

The Diff Lines count reports aligned rows, including unchanged rows. It is not a count of changed properties, additions, or deletions. An identical pair still produces aligned unchanged rows internally; the viewer’s empty-identical message is tied to whether rows exist, so do not treat that label as a semantic equality guarantee in every edge case.

How line alignment is calculated

For ordinary inputs, the comparator uses a longest common subsequence calculation over the normalized lines. Identical lines are anchors. Lines found only on the left become removals, and lines found only on the right become additions. LCS alignment generally keeps nearby shared structure together even when one side inserts several properties.

The algorithm’s work grows with the product of left and right line counts. To avoid locking the browser on large documents, the tool switches strategies when that product exceeds 1,000,000. The fallback compares lines at the same indexes instead of building the full LCS matrix. It remains responsive, but an insertion near the top can make many later lines appear changed because they are positionally offset.

This is a textual diff of normalized JSON, not a structural algorithm that emits property paths or JSON Patch operations. It does not label a moved array element as a move or pair renamed keys as one change.

High-value comparison scenarios

Check API contract drift

Compare captured responses from two deployments. Sorting suppresses object-order noise, allowing new fields, removed fields, type changes, and array changes to stand out. Samples cannot prove an entire contract, so pair this check with schema tests for production interfaces.

Review configuration between environments

Place staging configuration on the left and production on the right. Differences in flags, endpoints, limits, and nested settings become visible without requiring identical formatting. Remove credentials before sharing screenshots or copied input.

Diagnose a regression

Compare the last known good payload with a failing payload. A unified view gives chronological reading, while split view helps pair old and new values. For volatile fields such as timestamps and request IDs, manually remove them first if they obscure relevant changes.

Validate generated fixtures

Compare expected and generated JSON after a serializer change. Keep key sorting off if deterministic property order is itself part of the output requirement; otherwise leave it on to focus on parsed content.

Troubleshooting the diff

Diff Viewer is disabled

Both editors must be nonblank and parse successfully. Check each panel for Invalid JSON and read its detailed parser message. A valid left side cannot compensate for an incomplete right side.

Nearly every line appears changed

Enable key sorting if property order differs. If an array item was inserted near the beginning, the array’s remaining lines may legitimately shift. Extremely large inputs may also trigger positional fallback alignment, which is more sensitive to early insertions.

Two values look equal but still differ

Check string versus non-string types: "2" is not 2, and "false" is not false. Also inspect invisible characters inside strings, array order, capitalization, and Unicode differences. The tool does exact line comparison after parsing and serialization.

Formatting differences disappeared

That is intentional. Both sides are regenerated with two-space indentation before diffing. This page compares normalized JSON, not original whitespace or newline style.

Copy does not copy the highlighted view

The copy icons belong to the editors and copy their entered source text. The diff table has no copy or download action.

Important limitations

This comparator does not produce JSON Patch, Merge Patch, a changed-property summary, or a machine-readable report. It has no ignore-path rules, numeric tolerance, case-insensitive mode, array-as-set option, or semantic move detection. Changes are line additions and removals, with no inline character highlighting.

Parsing loses source details that JSON values do not retain, including duplicate keys and original numeric notation. Browser memory limits practical input size. The LCS fallback protects responsiveness but can reduce alignment quality. For automated gates or huge files, use a structural diff library or command-line workflow designed for those requirements.

JSON Compare FAQ

Are object keys sorted by default?

Yes. Sort keys alphabetically starts enabled and applies recursively to objects. Toggle it off to retain parsed property order.

Are arrays sorted too?

No. Array order is preserved. Sorting arrays could hide meaningful ordering changes or alter the represented value.

Does the tool identify modified values?

It represents them as a removed line and an added line. There is no dedicated modification category or character-level marker.

Why do line numbers differ from my pasted file?

They refer to the normalized, two-space JSON generated after parsing and optional key sorting, not to source editor lines.

Can it compare a root array or primitive?

Yes. Any two valid JSON values can be normalized and diffed, including arrays, strings, numbers, booleans, and null.

Does an empty diff prove semantic equality?

Matching normalized output is strong evidence that the parsed values serialize the same under these rules. It is not suitable for preserving duplicate keys, unsafe integers, or formal canonical-signature requirements.

Is there a maximum JSON size?

No fixed upload limit is enforced, but browser memory and rendering impose practical constraints. Above one million line-pair comparisons, the alignment deliberately switches to a simpler index-based method.

JSON Compare