Start a project

Tool 63 of 100 · API

OpenAPI Viewer & Linter

Open an OpenAPI or Swagger file and browse its endpoints, parameters and responses with example payloads, plus a list of problems to fix in the spec.

OpenAPI Viewer & Linter at a glanceIllustration: 1, An OpenAPI file; 2, processed in your browser; 3, Readable reference.OpenAPI Viewer & LinterGET/ordersPOST/orders1An OpenAPI file3Readable reference2In yourbrowser
1 An OpenAPI file 2 processed on your device 3 Readable reference

OpenAPI Viewer & Linter

OpenAPI file

Endpoints

    Endpoint detail

    Spec checks

      Markdown reference

      API reference in Markdown

      01

      What it does

      Reads OpenAPI 3.x or Swagger 2.0, lists every endpoint with examples built from the schemas, lints the spec and writes Markdown docs.

      • OpenAPI 3.0, 3.1 and Swagger 2.0, YAML or JSON
      • Every path and method with parameters and responses
      • Example request and response bodies from the schemas
      • Lint: missing operationIds, broken $refs, undocumented errors

      02

      Private by design

      Everything happens in your browser. Nothing you type, paste or upload is sent anywhere, and it keeps working offline once the page has loaded.

      03

      What you get

      Markdown API reference and a lint report, with a Copy and a Download button on every result.

      • OpenAPI
      • Swagger
      • REST
      • Docs

      Why it matters

      An OpenAPI file describes an API completely, but a 3,000-line YAML file isn't something you read. Most viewers need a server or send your spec to a third party, which isn't great for an internal API.

      This viewer reads the spec in your browser, lays out each endpoint with its parameters, bodies and responses, and builds example payloads from the schemas. The linter catches the problems that make generated clients and docs worse: missing operationIds, unresolved $refs, missing error responses and undocumented security.

      How it works

      1. InputOpenAPI 3.x or Swagger 2.0, YAML or JSON
      2. In your browser$refs resolved, operations checked
      3. OutputA browsable reference, example bodies and Markdown

      Where it fits in a designer's workflow

      1. Plan
      2. Design
      3. Build
      4. Test
      5. Launch
      Reading or reviewing an API.

      By the numbers

      The sample API spec, read by the toolGET: 2 operations; POST: 2 operations; Issues found: 4GET2 operationsPOST2 operationsIssues found4
      Counted by this tool's own loader and checks on its sample OpenAPI 3.1 file: operations by method, $refs resolved, and issues such as a missing operationId or a response without a schema. Source: OpenAPI 3.1.0.
      Show the numbers as a table
      ItemCount
      GET2
      POST2
      Issues found4

      How to use it

      1. Paste an OpenAPI or Swagger file, or open one.
      2. Browse the endpoints and pick one to see its detail.
      3. Fix the problems the linter lists.
      4. Download the Markdown reference.

      FAQ

      Which versions are supported?

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

      Does it follow external $refs?

      No. References to other files or URLs are listed but not fetched; references within the file are resolved.

      Can I try requests from here?

      No. It's a viewer and linter; nothing is sent to the API. Use the cURL converter to build calls.

      Is my spec uploaded?

      No. It's parsed in your browser.

      Work with me

      Want a site that gets these right?

      I build fast, accessible websites and web apps that pass these checks from day one. Tell me about your project and I'll reply personally with honest next steps.

      All developer tools · Back to leej.uk