# OpenAPI validator

> Validate an OpenAPI definition and score its design.

The OpenAPI validator checks an OpenAPI definition for syntax and schema errors, then scores its design out of 100 against a style guide of API best practices, listing every violation grouped by rule and auto-fixing the mechanical ones in place.

Also: swagger validator, swagger linter, swagger 2.0 validator, validate swagger online, openapi validator, validate openapi online, openapi linter, openapi schema validation, api design review, api style guide, openapi governance, lint openapi online.

## What it does

Validation tells you whether a definition is legal OpenAPI. It does not tell you whether the API is any good — a document can parse perfectly and still have no operation IDs, undocumented parameters, no error responses, and nobody to email when it breaks. This does both: syntax and schema errors are reported separately from a design score out of 100, with what each violation costs, and fixes applied for the ones whose correct answer follows from the document itself. Runs on Swagger 2.0, OpenAPI 3.0 and 3.1.

## When to use it

- You want to know whether an API definition is ready to publish, not just whether it parses.
- You are reviewing an API design and want an objective list of what is missing.
- You inherited a definition and want the mechanical problems cleared before you read it.
- You want to check a definition against design best practices without installing a linter or wiring up CI.

## What you give it

| Input | Meaning |
| --- | --- |
| OpenAPI definition | Typed directly, pasted in, opened from a local file, or imported from a URL. Supports Swagger 2.0, OpenAPI 3.0 and 3.1, in JSON or YAML. |

## What you get back

| Output | Meaning |
| --- | --- |
| Design health score | A score out of 100. Each violated rule deducts a fixed weight — 5 points for an error, 2 for a warning, 0.5 for a style issue — once, however many times it occurs. |
| Violations grouped by rule | Every finding, grouped by the rule it breaks, with the number of instances, the lines they sit on, and what the rule costs. |
| Auto-fixes | In-place fixes for violations whose correct value follows from the document — operation IDs derived from the method and path, trailing slashes removed, ignored keys beside a $ref deleted. |

## Key terms

- **API governance** — checking an API definition against agreed design rules — naming, documentation, error handling, versioning — so that a company’s APIs feel like one product rather than a dozen. The rules are usually called a style guide.
- **Linting versus validation** — validation asks whether the document is legal OpenAPI. Linting asks whether it is any good. This tool separates the two: syntax and schema failures are reported apart from the score, because a document that will not parse should not also be told its tags are untidy.
- **operationId** — a unique name for an operation. SDK generators turn it into a method name and documentation tools use it as an anchor, so an operation without one gets an auto-generated name that changes whenever the path does.
- **Deterministic auto-fix** — a fix whose correct value follows from the document itself, such as deriving an operationId from the method and path. Missing prose — a description, a contact email — cannot be auto-fixed, because inventing it would raise the score while making the document untrue.

## Questions

### Which formats are supported?

Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1, in JSON or YAML, detected automatically.

### Can I import Swagger specs into Postman?

Yes. Postman imports Swagger 2.0 specifications directly — validate here first, then paste the same file into Postman to generate a Collection you can run, test, and keep in sync with the spec.

### How is the score calculated?

Every violated rule deducts a fixed weight once — 5 points for an error, 2 for a warning, 0.5 for a style issue — regardless of how many times it fires, so the score starts at 100 and falls by the sum of the rules you break.

### Why can it not auto-fix everything?

Because most violations need information that is not in the document. An operation ID can be derived from the method and path, but a description, a contact email or a licence cannot be — writing a placeholder would raise the score while making the definition wrong.

### Does auto-fix preserve my comments and formatting?

Yes for YAML: fixes are applied as targeted edits to the exact bytes that change, so comments, quote styles and indentation elsewhere are untouched. JSON has no comments, and is re-serialised at the indent it was written with.

### Is my API definition uploaded anywhere?

Scoring and the deterministic auto-fixes run entirely in your browser, so nothing is sent anywhere. The one exception is Draft with AI, which is a separate button: pressing it sends the specific gaps it is filling to a model. If you never press it, the definition never leaves your machine.

### How many AI drafts do I get?

Three per day without an account. Scoring and the deterministic auto-fixes are unlimited.


## Privacy

Scoring and the deterministic auto-fixes run entirely in your browser — nothing is uploaded and no account is needed, which is what makes it safe to paste an internal or unreleased API definition. Drafting the missing documentation with AI is an explicit, separate action that does send the relevant excerpts to a model; everything else never leaves the page.

## Links

- [Use the tool](https://www.postman.com/tools/openapi-validator) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [API governance docs](https://learning.postman.com/docs/api-governance/api-governance-overview/) — Postman documentation.