# OpenAPI Editor and Visualizer

> Write, preview and lint an OpenAPI definition.

The OpenAPI visualizer and linter is a browser-based editor that renders an OpenAPI definition as live API documentation while you type, and reports validation and style problems as you go.

Also: swagger editor, swagger viewer, swagger 2.0 editor, swagger online, openapi editor, openapi viewer, openapi validator, openapi linter, openapi preview, api documentation generator, openapi visualizer, render openapi online.

## What it does

Editing an API definition in a plain text editor means you find out what you built only after generating docs. This shows both at once: the definition on one side, the rendered documentation on the other, and a diagnostics list underneath that updates as you edit. You can start from scratch, paste a definition in, open a local file, or import one from a URL.

## When to use it

- You are designing an API and want to see the documentation it produces as you write it.
- You inherited a definition and want to know whether it is valid before building against it.
- You want to preview how an endpoint will read to a consumer before publishing.
- You need to check a definition for problems 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. |

## What you get back

| Output | Meaning |
| --- | --- |
| Rendered documentation | A live preview of the definition as consumers would read it, updating as you type. |
| Diagnostics | Validation and style issues found in the definition, listed as you edit. |
| Validity indicator | Whether the definition currently parses. |

## Key terms

- **OpenAPI** — a standard, machine-readable description of an HTTP API — its endpoints, parameters, request and response shapes, and authentication. Formerly called Swagger, which is why 2.0 definitions still use a swagger key.
- **Linting versus validation** — validation asks whether the document is legal OpenAPI. Linting asks whether it is any good — missing descriptions, inconsistent naming, undocumented error responses. A definition can be perfectly valid and still be unpleasant to consume.
- **Design-first** — writing the API definition before the implementation, so the contract is agreed and reviewable before code exists. The alternative is generating a definition from code that already shipped, by which point the design decisions are made.
- **Specification version** — 3.1 aligned OpenAPI with JSON Schema, which changed how nullable types and examples are expressed. Definitions do not upgrade automatically between major versions.

## Questions

### What does this free Swagger / OpenAPI editor give you?

This free editor lets you author Swagger 2.0 or OpenAPI (3.0, 3.1) specifications in YAML or JSON and see them rendered as visual documentation instantly. Built-in validation flags syntax and governance issues as you write, so this Swagger editor catches problems before you ship.

### Which formats are supported?

Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1, in either YAML or JSON. Format and version are detected automatically.

### Can I import Swagger specs into Postman?

Yes. Postman imports Swagger 2.0 specifications directly. Once your spec is clean here, paste it into Postman to generate a Collection that stays in two-way sync with the spec as it evolves.

### What does Postman Spec Hub give you?

Spec Hub extends this into a visual editor with an outline view and code snippets, and covers OpenAPI, AsyncAPI, GraphQL, Proto, and Smithy in one place. You can generate a Postman Collection from your Specification and keep it in sync as the collection changes. You can define custom governance rules and use the Postman CLI to lint your spec in your CI pipelines. You can also sync specs to git and generate a full SDK straight from the finished spec.

### Can I turn this spec into something I can actually run and test?

Your spec generates a Collection you can run and test directly, staying in two-way sync as the spec evolves.

### How can I keep my collection in sync with the spec?

Spec Hub lets you update the collection once the spec is updated — this way your collections always stay in sync with the specification.

### Can I generate a specification from a collection?

Yes — you can start with a collection and enrich it with type information. The collection can then be converted into a specification and kept in sync, so Postman supports two-way sync between collections and specifications.

### Why does my validation error not make sense?

OpenAPI validation errors often point at a symptom rather than the root cause — a missing required field upstream can surface as an unrelated error several lines later.

### I need both REST and WebSocket support — should I use OpenAPI or AsyncAPI?

OpenAPI covers REST; AsyncAPI covers event-driven and WebSocket APIs. Spec Hub supports both in one place if your API needs both.


## Privacy

The definition is parsed, rendered and linted 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.

## Links

- [Use the tool](https://www.postman.com/tools/openapi-editor-and-visualizer) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [OpenAPI docs](https://learning.postman.com/docs/design-apis/specifications/overview/) — Postman documentation.