Practical guides
How to compare two JSON API responses before deployment
A safe workflow for comparing API JSON responses, formatting input, finding changed keys, and avoiding text-diff mistakes.
Updated 2026-06-03 · 6 min read
Why text diff can be misleading
API responses often change whitespace, property order, or formatting even when the data is equivalent. A plain text diff can make harmless formatting look like a large change.
JSON Diff works better because it formats valid JSON first and then compares the normalized structure.
Pre-deployment workflow
Capture the response from production and staging. Remove tokens, session IDs, and personal data before comparing.
Validate both JSON documents, format them, then compare. Focus on keys that changed meaning, not just timestamps or request IDs.
- Validate syntax before comparing.
- Normalize formatting so whitespace does not dominate.
- Ignore volatile fields such as requestId, timestamp, nonce, cache keys, or tracking IDs.
- Document unexpected additions, deletions, and type changes.
What to inspect
Look for deleted fields, renamed keys, array order changes, and value type changes. These are the differences most likely to break clients.
If a value changed from number to string, null to object, or object to array, treat it as a compatibility risk.
FAQ
Should I use text diff or JSON diff for API responses?
Use JSON Diff when both inputs are valid JSON. It formats structure first, which makes changed keys, arrays, and nested values easier to inspect.
What should I do if one response is invalid JSON?
Run it through JSON Validator first. Fix syntax errors before comparing, otherwise the diff will reflect formatting failure rather than data changes.
Can I compare private API data safely?
For normal MKDiff workflows, pasted JSON is processed in the browser. You should still remove secrets, tokens, passwords, and user-identifying data before sharing screenshots or reports.