Loading page
About this tool
Compare two JSON files, URL payloads, or text inputs side-by-side with semantic difference highlighting.
JSON Compare parses both inputs, re-serialises each one with two-space indentation, then aligns the two using a longest-common-subsequence diff so only genuine differences are highlighted — reformatting, minification and stray whitespace disappear before the comparison starts. Added lines are marked on the right panel, removed lines on the left, and a running count of each is shown above the result. You can paste the two documents, upload files, or fetch them from URLs, and invalid JSON is reported per panel with the parser's own error message.
Open JSON Compare on AltFTool — it loads instantly in your browser.
Fill JSON Document A (Left) and JSON Document B (Right): paste into each textarea, press Upload JSON to pick a .json file, or paste an endpoint into the "Paste JSON API URL to load (CORS enabled)" box and press Fetch. Load Sample JSON fills both sides at once.
Press Compare JSON Documents. Each side is parsed and re-serialised with JSON.stringify(value, null, 2) before the longest-common-subsequence diff runs, so minified-versus-pretty formatting never registers; a bad side is reported as "Invalid JSON inside Panel A" with the parser's own message.
Comparison Result shows Added lines and Removed lines counts, or "Both documents match 100%!", above two synchronised line-numbered panes with removals highlighted on the left and additions on the right. Clear All empties both inputs and the diff.
Both sides are parsed and re-printed at two-space indentation, so a minified document and a pretty-printed one compare as equal when their data matches.
The longest-common-subsequence pass keeps matching lines aligned across insertions, instead of reporting everything after an added field as changed.
Each panel is parsed separately and reports which side failed along with the parser's message, so you know whether A or B is malformed.
Yes. Both documents are parsed and re-serialised with `JSON.stringify(value, null, 2)` before the diff runs, so tabs versus spaces, minified versus expanded, and trailing whitespace never appear as differences. Only structural and value changes survive that step.
Yes, it does. Re-serialisation preserves the original key insertion order, so `{"a":1,"b":2}` and `{"b":2,"a":1}` are semantically the same object but produce four changed lines. Sort keys the same way on both sides if order is not meaningful to you.
Yes — paste a URL into each panel and fetch it. Because the request is made from your browser, the endpoint must send permissive CORS headers and be reachable without authentication; if it is not, copy the response body out of your API client and paste it instead.
The diff is a classic dynamic-programming LCS, so work grows with the product of the two line counts — two 1,000-line documents mean a million cells, which is fine, while two 20,000-line documents mean 400 million and will stall the tab. For very large payloads, compare the relevant subtree rather than the whole document.