Paste the earlier and updated definitions to create a change report. Confirm client impact with contract tests; external references are not fetched.
Runs locally in your browserBreaking change labels focus on removed operations, removed responses, and newly required inputs. Schema changes are flagged for review because compatibility depends on your clients.
Use this diff as a fast contract review, then confirm consumer impact in versioned API tests. External references and remote files are not resolved by this local checker.
Paste the specification you have released into Earlier specification and the proposed one into Updated specification, then press Compare specifications. Both boxes accept JSON or YAML, and both documents stay in the browser: nothing is uploaded, fetched or executed.
The result is a review report grouped by severity, with a JSON Pointer for every entry, so a finding can be traced back to the exact place in the newer document.
A removed operation, a removed required parameter, an optional parameter that became required, a newly required parameter and a request body that is now required are all listed as DANGER. So are a removed response status and a removed request content type, because existing callers may rely on them.
Schema edits are reported as WARNING rather than DANGER, because whether they break a client depends on the client: changed parameter, request and response schemas, removed or edited component schemas, and removed optional parameters. Editing a shared component is reported at /components/schemas/<name>, which is where a generated definition usually carries its breaking change.
When schemas are compared, the keywords required, enum, type, allOf, anyOf and oneOf are treated as sets, so a regenerated document that only reorders them is not reported as a change.
Operations are matched by method and path. A renamed path parameter therefore appears as one removed operation plus one added operation rather than as a single edit. References that point inside the same document (#/components/...) are resolved before comparing; external and remote references are not fetched, so a parameter or schema that only exists in another file is compared as it is written.
Swagger 2.0 documents are diffed the same way, because paths, operations, parameters and responses are read the same way. Servers, security requirements, tags, descriptions and examples are not compared.
Each entry has a severity (DANGER, WARNING, INFO or GOOD), the JSON Pointer of the affected element, and a sentence describing the change. ~1 in a pointer stands for a slash inside a path, so /paths/~1users/get is GET /users.
An empty box is reported as such, and a document that is not valid JSON or YAML is rejected with the line that failed, so a broken paste never looks like a clean comparison.