RunLocalTools

OpenAPI & Swagger Viewer: Browse, Lint, Compare and Export Specs Offline

Free OpenAPI and Swagger viewer that runs in your browser. Browse endpoints, generate examples and code snippets, lint, diff two versions, export docs. No upload.

What it does

Open an OpenAPI 3.0, 3.1 or Swagger 2.0 file (JSON or YAML) and get readable, searchable API documentation in seconds. You can browse every endpoint, see parameters, request bodies and responses as expandable schema trees, copy generated example payloads and ready-to-run code snippets, and check the spec for structural mistakes.

Beyond viewing, it can compare two versions of a spec and flag breaking changes, show which endpoints use each schema, and export your API as Markdown, standalone HTML, a Postman collection, or a fully resolved JSON/YAML file.

How it works

The spec is parsed in your browser. YAML is read with js-yaml; JSON uses the browser’s own parser, and a small scanner pinpoints the line and column of a syntax error.

  • References. $ref pointers are resolved against the document, including JSON-pointer escapes. Circular references (a Pet that contains an Owner that contains Pets) are detected and shown as “↻ circular reference” instead of looping.
  • Schemas. allOf is merged into one view. oneOf and anyOf are listed as variants, and discriminators, nullable and 3.1 type arrays, enums, constraints, read-only and write-only fields are displayed. Nodes expand lazily, so very large specs stay fast.
  • Examples. Sample values come from the spec’s own example/examples, then default, const and enum, and are otherwise generated from the type and format. Request examples leave out read-only fields; response examples leave out write-only fields.
  • Swagger 2.0. Old specs are converted internally to OpenAPI 3.0 for display (servers, definitions, body and form parameters, security definitions). That conversion can also be downloaded.
  • Comparison. Two specs are matched operation by operation. Direction matters: removing a response property is breaking for clients, while removing a request property is only a change. Detected breaking changes include removed operations or response codes, new required parameters or fields, type or format changes, narrowed request enums, tightened limits, and newly required authentication.
  • Linting. Checks include unresolved references, duplicate or missing operation IDs, path variables that don’t match declared parameters, invalid response codes, undefined security schemes and unused components.

How to use it

  1. Drop a .json, .yaml or .yml file onto the sidebar, paste a spec in the Source tab, or load the built-in sample.
  2. Search or filter the endpoint list by path, operation ID, tag, parameter name or HTTP method, then click an operation.
  3. Fill in parameter values, pick a server (variables are editable) and optionally enter credentials. The cURL, fetch, axios, Python and Go snippets update as you type.
  4. Open Lint to see problems (click one to jump to it), Models for every schema and where it is used, and Stats for an overview, including endpoints with no authentication.
  5. Open Compare, add a second version, and read the breaking-change report. Copy it as Markdown.
  6. Use Export for Markdown or HTML docs, a Postman collection, or a resolved or converted spec.

If your spec is split across files with relative references, drop all the files together and they are resolved as one bundle.

Need to turn an example response into types? Paste it into the JSON to TypeScript tool. If you only want to switch a spec between formats, the data format converter handles JSON, CSV and YAML. When an endpoint needs a bearer token and you want to see what is inside it, the JWT decoder will break it down, and the cURL to fetch converter is handy for adapting the generated cURL snippet to other styles.

Supported formats

  • OpenAPI 3.0.x and 3.1.x (3.2 is accepted on a best-effort basis), including webhooks and callbacks.
  • Swagger 2.0.
  • JSON and YAML, single files or multi-file bundles with relative $refs.
  • Exports: Markdown, standalone HTML (no scripts, no external requests), Postman collection v2.1, resolved JSON/YAML, original JSON/YAML, and Swagger 2.0 → OpenAPI 3.0.

Privacy

Your spec is read, parsed, linted, compared and exported entirely in your browser. Nothing is uploaded and there is no account.

  • Saved specs stay on your device. Specs you add are kept in your browser’s own storage so they are still there after a refresh. Each saved spec can be removed with its × button, and Clear all saved specs wipes everything. Credentials you type for snippets are held in memory only and are never saved.
  • Libraries. The first visit downloads three small, version-pinned libraries from a public CDN (a YAML parser, a Markdown renderer and an HTML sanitiser). None of your data is sent. After that the tool works offline.
  • Descriptions are sanitised. Markdown inside a spec is cleaned before display. Scripts are removed, and images are replaced by their alt text so a spec can never make your browser fetch something.

Two optional features use the internet. Both are off by default, behind unchecked boxes that reset every visit:

  1. Load a spec from a URL fetches the one URL you type.
  2. Try it out sends the request you built, from your browser, to the API server you selected. Credentials you entered are sent with it.

Everything else is local.

Limitations

  • The linter checks structure; it is not a full validation against the OpenAPI meta-schema.
  • Remote (http) $refs are not fetched. Download those files and drop them in together with the main spec instead.
  • “Try it out” only works with APIs that allow requests from web pages (CORS). If one doesn’t, copy the cURL snippet and run it from a terminal.
  • XML bodies appear only when the spec provides an example for them.
  • Swagger 2.0 → OpenAPI 3.0 conversion is best-effort. Check unusual specs.
  • In a multi-file bundle, circular references inside the extra files stay as internal pointers in the resolved export.
  • Very large specs (many megabytes) are parsed in the browser’s main thread, so expect a short pause.

FAQ

Is my API spec uploaded anywhere?

No. Parsing, linting, comparing and exporting all happen in your browser. The only network use is the two optional features above, and you have to tick a box to enable either one.

Why do I still see my spec after refreshing the page?

Specs you add are saved in your browser’s storage so a refresh doesn’t lose your work. Remove one with its × button, or use Clear all saved specs. Clearing your browser data also removes them.

How does it decide what counts as a breaking change?

It follows the client’s point of view. Anything that makes a previously valid request fail (a new required parameter or field, a narrower enum or limit, a type change, removed authentication-free access) or a previously reliable response unreliable (a removed field, a removed status code, a field no longer guaranteed) is flagged as breaking. Additions and loosened rules are reported as non-breaking.

Can it open a spec that is split across several files?

Yes. Drop the main file and the files it references together. Relative references like ./schemas/pet.yaml#/Pet are matched to the files by name and resolved locally.

Why does “Try it out” fail with a network error?

Most often the API doesn’t allow calls from web pages (CORS), or the server in the spec is only a relative path. Choose an absolute server in the sidebar, or use the cURL snippet instead.

Can I convert Swagger 2.0 to OpenAPI 3?

Yes. Open the 2.0 file and choose “Swagger 2.0 → OpenAPI 3.0” in the Export menu. It is a best-effort conversion, so review the result.