Read any OpenAPI or Swagger spec without installing anything
An API description file is precise but not pleasant to read: hundreds of lines of YAML where the response you care about is three $ref hops away from the endpoint. This OpenAPI viewer turns an OpenAPI 3.0 / 3.1 or Swagger 2.0 document into browsable documentation: endpoints grouped by tag with method badges, every parameter with its location, type and required flag, request and response schemas drawn as expandable trees with references already resolved, examples, and a ready-to-paste cURL command for each operation.
It is for developers integrating a third-party API from a spec file, reviewers checking a pull request that changes an API contract, and technical writers who need a quick Markdown reference.
The document is parsed in your browser and never uploaded. The viewer does not fetch URLs: if the spec lives on a server, download or copy it and paste it here, which also keeps internal APIs private.
How to use the OpenAPI / Swagger Viewer
- Paste the spec into the input, drop an
openapi.yaml/swagger.jsonon it, or press Load file. Use Sample OpenAPI 3 or Sample Swagger 2 to see a complete example. - Read the header: title, version, servers (Swagger 2
schemes+host+basePathare combined into URLs), contact, licence and the security schemes the API uses. - Open a tag group, then click an operation to see its description, parameters, request body, responses by status code and the security it requires.
- Expand the schema trees:
$reflinks are resolved in place, required properties are marked with*, enums, formats and constraints appear next to each type, and recursive references are shown with a↻mark instead of looping. - Use Search, Method and Tag to narrow a large API, and Copy as cURL to get a command with placeholders for every required parameter and an example body.
- Press Copy Markdown or Download .md for an API reference you can commit to a README or paste into a wiki.
OpenAPI / Swagger Viewer features
OpenAPI 3.0, 3.1 and Swagger 2.0
Both families render. Swagger 2 body and formData parameters become request bodies, produces/consumes become content types, and definitions are listed as schemas.
Reference resolution with cycle protection
Local $ref pointers to schemas, parameters, request bodies, responses and path items are followed, including JSON-pointer escapes. A schema that refers to itself (a category tree, a comment thread) is marked recursive rather than expanded forever.
Composition and constraints
allOf, oneOf, anyOf, not, enums, nullable and 3.1 type arrays, additionalProperties, read-only and write-only flags, formats, patterns, ranges and defaults are all shown.
Examples as the spec gives them
Media-type example and examples, property examples and Swagger 2 examples maps are shown; where none exists one is built from the schema.
Copy as cURL
Server URL with variables substituted, path and required query parameters, required headers, Accept and Content-Type, bearer / basic / API-key auth placeholders and a JSON, form or multipart body.
Markdown export
A complete reference — servers, each operation with parameter and response tables and its cURL, then one property table per schema — generated from the spec, not hand-written.
How Swagger 2.0 is mapped to the OpenAPI 3 view
The two formats describe the same things with different fields. The viewer normalises them so the page looks identical whichever you paste:
| Swagger 2.0 | Shown as |
|---|---|
schemes + host + basePath | One server URL per scheme, e.g. https://api.example.com/v2 |
Parameter with in: body | Request body with one entry per consumes media type |
Parameters with in: formData | A form request body (multipart/form-data when a file parameter or multipart consumes is present, otherwise URL-encoded) |
Parameter type/format/enum at top level | A schema object, as OpenAPI 3 expects |
Response schema and examples | Content per produces media type with its example |
definitions and securityDefinitions | Schemas and security schemes (basic becomes HTTP basic) |
What the cURL command contains, and what it cannot know
The command uses the first server in the list (server variables take their default value), the path with path parameters replaced by their example, default or a <name> placeholder, required query and header parameters, an Accept header from the first response media type and, for operations with a body, a Content-Type header plus an example body generated from the schema. The first security requirement of the operation (or the document default) adds a bearer token, basic-auth or API-key placeholder.
Optional parameters are left out so the command stays short. Values in angle brackets must be replaced before the request will succeed. To turn the command into JavaScript or Python, paste it into the cURL to Fetch converter.
Limits of this viewer
To tidy the file first, use the YAML Formatter or JSON Formatter, and the YAML ↔ JSON Converter to switch the serialisation.
- Only local references (
#/components/…,#/definitions/…) are resolved. References to other files or URLs are shown as unresolved, because the page never makes network requests. - Documents are rendered, not validated: a spec with a wrong field is shown as best it can be. Syntax errors in YAML or JSON are reported with a line number.
- Callbacks, links and webhooks are not rendered in this version.
- Specs up to 40 MB load; details are rendered on demand so large APIs stay responsive.
OpenAPI / Swagger Viewer FAQ
Is my API spec uploaded when I use this OpenAPI viewer?
No. Parsing and rendering happen in your browser. The only network request is the one-time download of the open-source YAML parser (js-yaml 4.1.0, MIT licence) from a CDN when the input is YAML.
Can I view a spec from a URL such as https://…/openapi.json?
Not directly — the viewer does not fetch URLs, so a private API behind a login or a firewall stays private. Open the URL in a browser tab, copy the text, and paste it here.
Does it support Swagger 2.0 as well as OpenAPI 3?
Yes. Swagger 2.0 (the format before the OpenAPI rename) and OpenAPI 3.0.x and 3.1.x all render, with Swagger fields mapped as in the table above.
Why does a schema show a ↻ mark?
That property references a schema that is already open higher up the same tree — a recursive structure such as a category with a parent category. The viewer stops there instead of expanding forever; open the schema from the Schemas section to inspect it on its own.
Why is a parameter marked required when the spec does not say so?
Path parameters are always required by the OpenAPI and Swagger specifications, so the viewer shows them as required even if the required field was omitted.
Can I turn the spec into documentation?
Yes — Copy Markdown or Download .md produces a reference with a section per tag, parameter and response tables, a cURL snippet per operation and a property table for every schema.