Text Compare

Comparing two API responses

Paste the baseline response on one side and the current response on the other. The tool reports differences line by line, which makes it useful for the everyday question of what changed between two runs, two environments, or before and after a deployment.

One preparation step decides whether the result is readable. Format both documents the same way first: if one side is minified and the other is pretty-printed, every single line differs and the diff tells you nothing. Once both are formatted with identical indentation, the real changes stand out.

Two properties of JSON are worth holding in mind while reading the result. Object key order carries no meaning in JSON but a line-based diff treats a reordered key as a change, so a serialiser upgrade can produce a large diff with no behavioural difference. Array order usually does carry meaning, so a reordered list is a genuine change even when the same elements are present, and it is exactly the kind of change that breaks a test asserting on the first element.

Diffing configuration between environments

Works in staging, fails in production is usually a configuration difference, and the fastest way to find it is to put both configurations side by side. Export both, paste them here, and read the differences. Expect legitimate divergence in hostnames, credentials and scaling values: the interesting lines are feature flags, timeouts, retry counts and version pins that were never meant to differ.

Before you paste anything, strip the secrets. Environment configuration is the most common place for API keys and connection strings to hide, and a habit of removing them protects you regardless of which tool you happen to be using.

Finding invisible characters

Some of the most frustrating defects come from characters you cannot see. Two strings look identical on screen and a comparison still reports them as different. The usual suspects:

• Trailing whitespace at the end of a line, often added by an editor on save.
• A tab where the other side has spaces, which matters in YAML and in anything whitespace-sensitive.
• Windows line endings on one side and Unix on the other: every line differs even though nothing changed.
• A non-breaking space pasted from a word processor, browser or chat client in place of a normal space.
• A byte order mark at the start of a file, invisible everywhere but fatal to a JSON parser.
• Visually identical Unicode characters, such as a Cyrillic letter standing in for a Latin one in a test username.

If a comparison flags a line whose two versions look the same, one of the above is almost always the reason. That is a genuine finding rather than a tool artefact, because whatever consumes the file sees the difference too.

Verifying test data before and after a run

1. Capture the record or export before the action under test.
2. Run the action.
3. Capture the same record afterwards and compare the two.
4. Check that only the fields you expected to change did. Unexpected changes to timestamps, version counters or audit fields are frequently the real defect and are easy to miss when you only assert on the one field you were testing.

This is also a practical way to review a bug report. Paste the reporter’s expected output and the actual output, and the disagreement becomes concrete rather than a description.

What a line-based comparison will not do

Being clear about the limits saves time. A line-based diff does not understand structure, so it cannot tell you that two JSON documents are semantically equal despite different key order: for that you need a structural comparison. It does not ignore fields that are expected to change, so timestamps and generated identifiers will always appear as differences unless you strip them first. And it compares text, not rendered output: two HTML documents that display identically can differ substantially in source.

Frequently asked questions

How do I compare two JSON files properly?

Format both with the same indentation first, then compare. For a semantic comparison that ignores key order, parse both and compare the resulting structures instead: a text diff cannot do that on its own.

Why does the comparison show a difference when the lines look identical?

Almost always an invisible character: trailing whitespace, a tab versus spaces, mixed line endings, a non-breaking space, or a byte order mark. All of them are real differences that whatever reads the file will also see.

Can I compare two files rather than pasted text?

Open each file and paste its contents into the two panels. For a repository, a version control diff is the better tool because it understands history; this is for the everyday case of two snippets that are not both in a repository.

Does the text I paste get uploaded?

No. The comparison runs in your browser, which matters here because the things people most often diff are configuration files and API responses containing real data.

How do I ignore fields that always change?

Remove or normalise them before comparing: replace every timestamp with a fixed placeholder, strip generated identifiers. In an automated suite this normalisation step belongs in the test itself so the comparison stays meaningful over time.

What is the difference between a line diff and a word diff?

A line diff marks a whole line as changed even if one character differs, which is ideal for structured text like JSON or configuration where lines are meaningful units. A word diff highlights the exact token and suits prose. For QA work on data and config, line-based is usually the clearer view.