How is this different from Postman's built-in diff feature?
Postman has a response comparison view inside its Collection Runner and a Visualize feature for individual responses. Both are good if you live in Postman and your responses are already saved as Postman history items. This tool is provider-agnostic. You can paste from Postman, Insomnia, curl, httpie, a CI log, a Stack Overflow snippet, or a colleague's Slack message. There is no account, no workspace, no sync. For one-off comparisons across tools, that is faster. For team-shared API testing inside a single platform, Postman's own feature is fine.
How do I handle volatile fields like timestamps and request IDs?
The pragmatic move is to normalize before diffing. Open both pastes in the panes, then edit out the volatile fields directly: replace timestamps with a constant string, strip request_id and trace_id values, remove pagination cursors that change every call. The diff highlights only the remaining differences, which are the ones that actually matter. For repeated comparisons of the same endpoint, you can also pipe the response through jq with a delete filter (jq 'del(.meta.request_id)') before pasting.
How is this different from an OpenAPI schema diff?
Schema diff compares contracts: it tells you that POST /orders added an optional discount_code field, or that the status enum gained a new value. OpenAPI-aware tools like oasdiff or Spectral do this well. This tool compares actual response bodies. The two are complementary. Schema diff catches contract changes; response diff catches drift between the contract and reality, which is where serialization bugs, environment mismatches, and stale fixtures hide.
Can it handle large responses?
Practically yes, up to a few thousand lines of pretty-printed JSON on each side. Beyond that the character-level diff with semantic cleanup gets slow because it runs in your browser, not on a server. For very large payloads (think a paginated dump of 10,000 records), the right approach is to slice the response into smaller pieces by record or by top-level key and diff each piece separately. Or run a structural diff on the command line with jd or diff <(jq . a.json) <(jq . b.json) for raw speed.
Does it work for XML or SOAP responses?
Not directly. This page is tuned for JSON, which is what most modern REST and webhook payloads use. If you need to diff XML, SOAP envelopes, RSS, or POM-style configuration, our compare-xml tool is the right surface; it handles indentation and namespace formatting correctly. For raw response bodies that mix headers and body, or for plain-text APIs (some legacy systems still return text/plain), compare-text does the job without trying to enforce a structure.
Does it preserve key order or sort keys?
It preserves the key order you paste. JSON objects are formally unordered per RFC 8259, so two semantically identical responses with keys in different orders will show as a diff in this tool. If you want to ignore ordering, normalize both sides first by piping through jq --sort-keys or an equivalent. Most clients do not depend on key order, so sorted-key normalization is a safe default for response comparison; just be aware some legacy consumers (older XML-to-JSON bridges, certain digital-signature flows) do care about order.
Does this work for GraphQL responses?
Yes. GraphQL responses are JSON envelopes with the standard { data, errors, extensions } shape, so the diff just works. The wrinkle is that the client controls which fields come back and in what order; the same query reissued with reordered selections produces a textually different response that is semantically the same. Arrays inside data are also not guaranteed to preserve order across resolvers. Volatile fields are usually scoped to extensions (tracing, request IDs, cache hints), so strip those before diffing. For schema-level changes, reach for a dedicated tool like graphql-inspector rather than this one.
Can I diff a gzipped or protobuf response body?
Not directly. Both are binary. Pasting gzipped bytes will look like garbage, and a Protobuf message has no canonical text form because field tags are integers and types depend on the .proto definition. For gzip, ungzip first with gunzip < file | jq ., or in Chrome DevTools open the Network tab and use the Response view, which shows the decoded body. For Protobuf, run protoc --decode_raw for a structure-only view, or grpcurl with the matching .proto for a typed text rendering. Once you have human-readable text, paste both sides into the diff.
Is it safe to paste a response with auth tokens or customer data?
Yes. The diff runs entirely in your browser; nothing is uploaded, logged, or sent anywhere. That matters here because real responses leak Authorization bearer tokens, Stripe customer IDs, session cookies, and PII into body fields all the time. Pasting those into a server-backed diff site would be a genuine data-handling event under GDPR or your SOC 2 controls. Want to check? Open DevTools, watch the Network tab while you paste, and confirm nothing leaves the page.
Is it free, and do I need to sign up?
Free, and there is no account to create. No trial, no seat limit, no email gate. Paste two responses, read the diff, close the tab. Every button, Format, Upload, and Sample, works on the first visit with no login. It is a single-purpose utility, not a freemium funnel, so there is no locked tier hiding the part you actually came for.
Can I compare more than two responses at once, like across three environments?
Not in one view; the tool is built around two panes. For a three-way case, say the same endpoint on dev, staging, and prod, run it twice: dev against staging, then staging against prod. Reading two clean diffs in turn is easier than squinting at three columns of JSON. If you genuinely need an N-way structural compare, that is a command-line job with jq and diff rather than a paste tool.
Can I upload two saved response files instead of pasting?
Yes. Click Upload on either pane and pick a saved .json file, like a curl dump or a checked-in test fixture. The browser reads it locally through the File API, so the file never leaves your machine. Uploading one side and pasting the other is common: load the committed fixture from disk, paste the live response from your terminal. There is no format gate; if it is text, it loads.
Does it work offline, and can I use it on a phone?
Both. The diff is client-side JavaScript with no server call, so once the page has loaded you can drop your connection and it keeps working, which is handy on a locked-down build box or behind a flaky VPN. On a phone the two panes stack vertically and pinch-zoom works, though a dense JSON response is genuinely easier to read on a laptop where both columns fit side by side.
