Problem solved by Diff Anything
Compare OpenAPI and JSON Schema locally, flag likely breaking changes, and keep API contracts off an online comparison service.
See it in the app
No accounts, cloud comparison service, analytics, or telemetry.
The problem
A line diff can make reordered YAML or JSON look important while hiding the contract changes that can break an existing API consumer: removed operations, narrower schemas, changed parameters, or new requirements.
The solution
Diff Anything parses OpenAPI and JSON Schema as contracts, labels likely breaking changes with heuristic rule codes, and shows a breaking-change verdict and count. With Pro on Windows, the CLI and batch manifests run the same comparison in CI and can fail the job only on breaking or unclassified changes.
01 / Contract review
The baseline is the contract existing consumers already use; the candidate is the proposed replacement. That direction matters because removing an operation or narrowing an accepted value has a different compatibility effect from adding one.
Keep the source versions available during review. A rule match is evidence for a release decision, not a substitute for understanding the affected consumer workflow.
02 / Contract review
Review removed or newly required contract elements first, then examine changes whose effect depends on consumer behavior or runtime semantics. Compatible additions still deserve review when undocumented behavior or custom validation exists.
The comparison describes the contract it can parse. Runtime behavior, server implementation, and undocumented expectations remain outside that evidence.
03 / Contract review
With Pro on Windows, run diff-anything --cli --mode api --fail-on breaking, or set failOn: breaking for a case in a batch manifest. Identical or equivalent schemas pass, non-breaking changes are allowed, and the job fails on breaking changes and on changes the rules could not classify. JUnit and SARIF output list each finding with its rule code, such as API001 for a removed operation.
The rules are heuristic: $ref is compared as written rather than resolved, request and response schemas are treated alike, and some breaking changes are not classified, such as a removed components entry, a renamed or relocated parameter, or added additionalProperties: false. Treat a passing check as a first gate, not proof of compatibility, and keep the same baseline direction locally and in CI.
Clear answers
No. Contract comparison focuses on parsed operations, parameters, schemas, and compatibility-oriented changes rather than source line movement alone.
Yes. With Pro on Windows, --fail-on breaking or a batch case with failOn: breaking fails the job only on breaking or unclassified changes, and identical schemas pass. Batch manifests emit JSON, JUnit, or SARIF with each finding's rule code. The rules are heuristic, so contract review is still needed.
No. Runtime behavior, custom validation, undocumented expectations, and semantic meaning still require human review and testing.
Three short steps
Open the baseline and candidate contracts.
Let Auto choose API Schema mode, or select it.
Review the flagged changes first, then check the rest of the result.
Available for macOS and Windows