Local-first release review

API spec diff in one page

Paste or load two OpenAPI or JSON Schema documents, classify the changes, review risky items, and copy release-ready drafts without sending the raw spec to a server.

Trust strip

OpenAPI 3.0/3.1 supported · JSON Schema beta · browser-local processing · auth/default/required changes stay in the review queue

Open workbench

Compare workspace

Sample compare

Move from raw specs to release-ready wording in a calmer, step-by-step flow.

Runs locally in your browser. Raw specs are not uploaded.

Previous spec

previous-spec.yaml

Your semver recommendation, risky items, and copy-ready drafts will appear here after both specs are loaded.

Severity summary

No structural changes were detected.

Why this recommendation

Your semver recommendation, risky items, and copy-ready drafts will appear here after both specs are loaded.

Next step

Scan the classified changes list.

What does this route answer first?

It helps you answer whether the change is breaking, what semver bump is safer, and what you can say in release notes before the team ships.

  • Use the compare workbench when you already have a previous spec and a proposed next spec.
  • Treat auth, default, nullable, required, and enum changes as review-required until a human confirms the impact.
  • Copy-ready drafts keep the output practical for PM, Tech Writer, SDK, and backend review loops.

How to use the workbench

  1. 1.Load or paste the previous and next spec documents.
  2. 2.Run compare and review the severity summary before scanning the list.
  3. 3.Resolve risky items, then copy the release note or migration draft that matches the audience.

Trust signals

  • Runs locally in the browser
  • No raw spec upload to Konviny servers
  • Manual review queue for risky rule categories
  • Semver recommendation updates after each review decision
Maintained by: Konviny Tools team
Last updated: 2026-03-07

FAQ

Support content, kept below the tool.

Does the compare run entirely in the browser?

Yes. The MVP is designed as a local-first workbench, so the raw previous and next specs stay in the browser while the diff report is generated.

Why are some changes marked as needs review instead of breaking or non-breaking?

Changes like auth, default, nullable, required, and enum updates depend on rollout context and consumer expectations, so the tool keeps them in a manual review queue.

Can I save a baseline for later?

Yes. The current previous spec can be saved in local browser storage and loaded back into the compare workbench later.