OpenAPI Validator

Paste or upload an OpenAPI document and see every error with its JSON pointer and line number, plus a few lint warnings. It is free, needs no account, and your document never leaves your browser.

The sample above is a small Galaxy Planets API with one deliberate mistake: a 200 response without a description, which OpenAPI requires. Click the error to jump to the line, add a description, and the result turns green.

How the OpenAPI validator works

Validation happens in three steps, all inside this page.

1. Parse. Your text is read as JSON if it starts with { or [, and as YAML otherwise. Syntax problems (a missing quote, bad indentation, a duplicate key) are reported with a line and column before anything else runs.
2. Validate. The parsed document goes to validate() from @scalar/openapi-parser. It detects the version from the swagger or openapi field, checks the document against the official schema for that version, resolves every local $ref, and checks that each templated path parameter such as {planetId} is declared.
3. Lint. Once the document is valid, a handful of extra checks run. They catch things that are allowed by the specification but make generated documentation, SDKs, and MCP tools worse.

Each error shows a JSON pointer, like /paths/~1planets~1{planetId}/get/responses/200. In a pointer, ~1 stands for / and ~0 for ~, so that one reads "the 200 response of GET /planets/{planetId}". The tool maps pointers back to line numbers in your original text, whether you pasted JSON or YAML.

What it checks

Limits

• Local references only. References to other files or URLs ($ref: './schemas/planet.yaml') are not fetched, because the tool never makes network requests with your document. Bundle multi-file documents first, for example with npx @scalar/cli document bundle.
• Not a Spectral replacement. The lint checks are a small fixed set. For your own style guide, write Spectral rules and run npx @scalar/cli document lint in CI.
• Size. Uploads are capped at 10 MB. Very large documents validate, but share links for them get too long to be practical.
• First error wins for structure. When the structure is invalid, reference and lint checks wait until it is fixed, so fixing one error can reveal the next.

Validate in CI with the Scalar CLI

The browser tool is for quick checks. To stop invalid documents from being merged, run the Scalar CLI in your pipeline:

npx @scalar/cli document validate openapi.yaml

The Scalar CLI commands page lists validate, lint, bundle, and upgrade. If you keep your API descriptions in the Scalar Registry, you can store shared Spectral rules there and lint every document against the same ruleset.

Built on @scalar/openapi-parser

This page uses @scalar/openapi-parser, the MIT-licensed OpenAPI parser that Scalar maintains in the same open-source repository as the API reference and API client. The page loads it and the yaml package from jsDelivr, pinned to exact versions. To validate in your own code:

import { validate } from '@scalar/openapi-parser'

const { valid, errors, version } = await validate(document)

document can be a JSON string, a YAML string, or an object. The source for this tool is in the scalar/scalar repository under documentation/assets/free-tools.

Turn a valid document into docs

A valid OpenAPI document is all Scalar needs to publish an interactive API reference, generate SDKs, and host an MCP server.

Frequently asked questions

Related

• Learn: Spectral rules for OpenAPI · What is OpenAPI?
• Docs: Scalar CLI commands · OpenAPI converter · OpenAPI diff
• Product: Scalar API References — turn the document you just validated into interactive docs