Compare two versions of a format and see what breaks
Put the current contract on the left and the new one on the right. Each change is listed and marked as breaking or safe, and you can test real messages against the new version.
Loading the tool…
What counts as a breaking change
A change is breaking when a sender that satisfied the old version can be refused by the new one.
| Change | Breaks senders? |
|---|---|
| Maximum length reduced, or added where there was none | Yes |
| Maximum length raised or removed | No |
| Optional field becomes required | Yes |
| New required field | Yes |
| New optional field | No |
| Allowed value removed | Yes |
| Allowed value added | No |
| Type changed (integer to number excepted) | Yes |
| Date format changed | Yes |
| Field removed while unknown fields are refused | Yes |
| Unknown fields go from accepted to refused | Yes |
From a list of changes to a number of failures
A list of changes says what could break. Real messages say what will. Paste a file or a payload that passes today into the optional box: the tool counts how many of its records the new version would refuse, and lists them.
A validation endpoint does this with its own journal: before you save a new version, it tells you how many of the last accepted messages would stop passing.
Questions
- Which formats can I compare?
- Two contracts as used by this site: a list of fields with a type and limits. Build each side in the table, or paste it as JSON.
- Can I compare two JSON Schema or OpenAPI files?
- No. This compares the simpler contracts used here. For an OpenAPI description, use an OpenAPI diff tool.
- Is anything uploaded?
- No. Contracts and sample messages stay in your browser.