OpenAPI YAML Validator

Paste your openapi.yaml and the validator checks the parts every spec needs: a version field, an info object with a title and version, and a paths object. It also warns about path keys without a leading slash and operation keys it does not recognize.

How to validate an OpenAPI YAML file

  1. 1

    Copy the YAML

    Copy the full contents of your `openapi.yaml` or `swagger.yaml`, keeping the indentation exactly as it is.

  2. 2

    Paste into the field

    Paste it into the OpenAPI / Swagger document box. Indentation is the structure in YAML, so do not retype or reflow it.

  3. 3

    Run the validation

    Continue to the results step and read the errors and warnings.

  4. 4

    Correct and recheck

    Fix each reported item in your file, paste the new version and run it again.

Why indentation matters for the result

In YAML the nesting of keys decides which object a field belongs to. If version sits at the same indent as info instead of one level under it, the document is still readable YAML, but info.version is missing and the check reports it. The same applies to paths: a path key indented under info by mistake means the top-level paths object is gone.

Use spaces, not tabs, and keep a consistent step such as two spaces per level.

A worked example

openapi: 3.0.3
info:
  title: Pets API
paths:
  /pets:
    get:
      summary: List pets

The version field, info.title and paths are all present, and /pets starts with a slash with get as a known method. One thing is missing: info.version. The report lists:

Finding Type
info.version is required. Error

Add version: 1.0.0 under info, indented two spaces, and the document is reported as structurally valid.

Keep documents simple for a reliable read

The check reads ordinary YAML mappings best: plain key: value lines nested with consistent indentation. If a document with advanced YAML features such as anchors or multi-line blocks is reported as unreadable or shows fields as missing, try a JSON copy of the same spec to confirm whether the problem is the content or the YAML syntax.

A clean result confirms the skeleton only. It does not resolve $ref links or check schemas.

A practical workflow for YAML specs

Edit in small steps and recheck. After you add a new path or move a block, paste the file again so a bad indent is caught while the change is still fresh. When you split a large spec across several files, paste the combined version, because this check reads only the text you give it and does not load other files. Copy from your editor rather than from a rendered page, since web pages can replace spaces and quotes with look-alike characters that change how the YAML is read.

Finally, remember that the report lists only what the check can see. A clean result on a YAML file means the top-level skeleton is correct, not that every operation, schema or reference inside it is.

Frequently Asked Questions

Spaces. YAML does not accept tabs for indentation, and a tab can make the document unreadable or push fields to the wrong level.

Usually the field is indented at the wrong level, so it belongs to a different object than you intended. Compare its indent to the parent key.

This check only looks for the presence of the openapi or swagger field, not its value, so quoted and unquoted versions both pass. Quoting "2.0" for Swagger is still a good habit.

Yes. The document is read as JSON first and as YAML if that fails, so either format works in the same field.

Related Tools

Tool available in other languages

Guides and use cases