How to Compare API Responses Before & After Changes

You are about to deploy an API change — maybe a database migration, a refactored endpoint, or an updated third-party dependency. The change should not affect the response structure, but “should not” and “does not” are very different things. The safest approach is to capture the API response before the change, deploy, capture it again, and compare the two. This workflow makes that comparison fast and precise.

Before You Deploy: Capture the Baseline

Hit your API endpoint with the same parameters you will use for testing after the change. Save the raw response body as a text file. Do this for every critical endpoint and every important parameter combination. These baselines are your source of truth for what “correct” looks like.

Step 1: Format Both Responses

Raw API responses are typically minified — one long line with no whitespace. Comparing minified JSON is nearly impossible visually. Paste each response into the JSON Formatter to produce clean, indented output. This step also validates the JSON: if your change accidentally broke the response structure (a missing closing brace, an extra comma), the formatter catches it immediately. Format both the “before” and “after” responses and keep them in separate tabs or text files.

Step 2: Diff the Formatted Outputs

Now paste the formatted “before” response into the left panel of the Text Diff tool and the “after” response into the right panel. The diff highlights every difference: added fields, removed fields, changed values, reordered keys. This is where you find out whether your “non-breaking change” actually broke something.

Common findings during API diffs:

• New fields added: Usually safe, but downstream consumers may choke on unexpected keys if they use strict parsing.
• Fields removed: Breaking change. Any consumer relying on that field will fail.
• Value type changes: A number that became a string, or a single object that became an array. Subtle but dangerous.
• Key reordering: Technically valid JSON, but some poorly written parsers depend on key order. The diff reveals this so you can investigate.
• Timestamp/ID differences: Expected changes that you can safely ignore.

Step 3: Decode Base64 Payloads

Many APIs include Base64-encoded data inside JSON responses: embedded images, encrypted tokens, serialized objects, or binary data represented as strings. If the diff shows a change in a Base64 field, you need to decode both versions to understand what actually changed. Paste each Base64 string into the Base64 Decoder and compare the decoded content. If the decoded content is itself JSON, format it with the JSON Formatter and diff again. This recursive approach catches changes nested deep inside encoded payloads.

Automating This for CI/CD

While this manual workflow is ideal for one-off checks and debugging sessions, the same principle scales to automated testing. Capture baseline responses as fixture files in your test suite, run your API after changes, and diff programmatically. The manual workflow described here is perfect for investigating failures that your automated tests flag — when a test says “response mismatch,” these tools help you understand exactly what mismatched and why.

Quick Reference

1. Capture before and after API responses.
2. Format both with the JSON Formatter.
3. Diff them with the Text Diff tool.
4. Decode any Base64 fields with the Base64 Decoder.
5. Investigate every unexpected difference before deploying to production.