OpenAPI Compatibility Checker
A tool that compares OpenAPI 3.0.x definitions (JSON or YAML) before and after a change and detects changes that affect existing API clients, such as removed paths and methods, newly required request fields, and type changes. Each finding shows the location, before and after, and why it matters, grouped by endpoint. Parts that can't be checked, such as external references, are marked unchecked — all processed in your browser.
- Supports OpenAPI 3.0.x definitions in JSON or YAML. OpenAPI 3.1 and Swagger 2.0 are not checked.
- Detects removed paths and HTTP methods; parameters, request bodies, and request properties that became required; type changes; and nullable changes. Paths that differ only in parameter names (/users/{id} → /users/{userId}) are treated as the same endpoint.
- $ref within the same document is resolved. References to external files or URLs and schemas using allOf, oneOf, anyOf, or not are reported as unchecked. enum, format, removed response properties, and more are not checked, so no findings doesn't guarantee full compatibility.
Compatibility result
Enter the OpenAPI definitions before and after the change to see changes that affect existing clients.
How to use
- Paste the definition before the change on the left and after on the right (JSON or YAML), or load files.
- Changes that affect compatibility are grouped by method and path.
- Check each change's location (parameter, request body, or response, plus the property path) and why it matters.
- "Unchecked" marks parts this tool can't evaluate, such as external references or composed schemas. Review them manually as needed.
About this tool
When an API changes, making an optional request field required or changing a response type can break older clients. This tool compares definitions by their OpenAPI meaning to catch these changes before release.
Key order, formatting, and JSON versus YAML aren't treated as changes. Paths that only rename a path parameter (/users/{id} → /users/{userId}) are compared as the same endpoint. Changes that widen what requests accept, such as integer to number, are compatible, and the reverse applies to responses.
The check is limited: enum, format, removed response properties, security definitions, and more are not covered, so no findings doesn't guarantee full compatibility. Your definitions are never sent to a server.
Use {"openapi":"3.0.3","paths":{"/ping":{"get":{"responses":{"200":{"description":"ok"}}}}}} as the old definition and {"openapi":"3.0.3","paths":{}} as the new one. Removing /ping is reported as a breaking change.
The comparison asks whether existing clients can use the changed API. Reversing the inputs turns a removal into an addition and changes the result. Put the released definition on the left and the proposed definition on the right, then review unchecked references alongside the findings.
Frequently asked questions
Does it support OpenAPI 3.1 or Swagger 2.0?
This version supports only OpenAPI 3.0.x. Other versions are reported as unsupported and not checked.
Are $ref references resolved?
References within the same document, such as #/components/schemas/User, are resolved. External files and URLs are never fetched and are marked unchecked.
Are new endpoints listed?
Additions don't affect existing clients, so they aren't listed. Use the JSON Structural Diff to see every difference.