API Contract Checker

You paste (or upload) a base (old) and a revision (new) OpenAPI 3.x specification, and it walks every path, parameter, request body, response, security requirement, and schema in both, then reports what changed: added or removed endpoints, parameter and request-field requirement changes, narrowed types or enums, response fields or status codes that disappeared, security requirement changes, and allOf/oneOf/anyOf composition changes.

Anything that could stop an existing client from working: a removed endpoint, a parameter or request field that became required, a response field or status code that was removed, a field that is no longer guaranteed in a response, or a type/enum that got narrower (including OpenAPI 3.1 nullable type arrays, e.g. removing "null" from `["string", "null"]`). New endpoints, new optional fields, and new response fields are additive and shown separately as safe.

Yes. Added/removed security requirements (global and per-operation), security scheme definition changes (e.g. an API key moving from a header to a query parameter), newly-deprecated operations, and server URL changes are all reported - as informational findings rather than breaking or safe, since (matching the default severity oasdiff itself assigns these checks) neither direction is universally right or wrong; you decide whether it matters for your API.

Yes. `allOf` members are resolved and merged before diffing, so a required field added deep inside a composed schema is still caught. `oneOf`/`anyOf` variant sets are compared and flagged as informational when a variant is added or removed, since whether that specific change is breaking depends on how your clients discriminate between variants.

No - this compares OpenAPI 3.x specs only. Swagger 2.0 (the older format) structures parameters and bodies differently, so applying the same rules to it would give wrong answers. Pasting a Swagger 2.0 document produces a clear error instead of a silently wrong diff.

No. Parsing and comparison both run in your browser - your spec never leaves your device, unlike most other OpenAPI diff tools, which process the upload on their own server even when they say they don't store it. This is also true when you use the file upload/drag-and-drop option: the file is read locally, never transmitted.

It compares `application/json` request and response bodies, which covers the large majority of REST APIs, but it does not evaluate other content types, response headers, descriptions, or examples. A `$ref` that points outside the document (a separate file or URL) is reported as unresolvable rather than silently skipped.

Yes to both. Each box accepts JSON or YAML independently and detects which one you used, so you can compare a JSON base spec against a YAML revision or vice versa. You can also drag a .json/.yaml/.yml file onto either box, or use its Upload file button - the file is read in your browser and never uploaded anywhere.

It works against any document with an "openapi": "3.x" field and a "paths" object, which covers both 3.0 and 3.1 - including 3.1's array-form `type` (e.g. `["string", "null"]`) - and only rejects documents that look like Swagger 2.0 instead.

Text (.txt), Markdown (.md), and JSON (.json) are all supported - pick one from the format dropdown next to Download report before you download. The JSON export includes the full list of findings plus per-severity counts, so it can be piped into another script (e.g. a CI check) if you need that.

Both work: press Compare for an instant re-run, or just keep typing - after a brief pause it re-compares automatically. You can also press Ctrl+Enter (Cmd+Enter on Mac) from either box to compare immediately without waiting.