Search DevTools

Jump to any tool or page

OpenAPI / Swagger Explorer

Paste or upload an OpenAPI 3.x or Swagger 2.0 document to browse every endpoint, resolve $refs, generate realistic examples, and copy ready-to-run cURL commands — entirely in your browser.

Load spec

Overview

Paste or upload a spec on the left to get started.

API Development

About OpenAPI / Swagger Explorer

Load an OpenAPI or Swagger document and browse its paths, operations, schemas, and security requirements as navigable structure rather than raw YAML. Specifications lie more often than people expect — the document describes intent, and drift from the running service is normal wherever the spec is hand-written rather than generated from the implementation.

Related API Development tools

Email ValidatorAPI Test SimulatorAPI to ModelsWebhook TesterPhone Validator

Frequently asked questions

What changed between Swagger 2.0 and OpenAPI 3.x that breaks tooling?
The definitions section became components/schemas, so every internal reference path changes. Body parameters were replaced by requestBody with a content map keyed by media type, which finally allows one operation to accept several formats. The single host, basePath, and schemes fields became a servers array supporting variables and multiple environments. Security definitions moved and gained OAuth2 flow restructuring. A 2.0 document loaded by a 3.x-only parser typically fails on the missing openapi version field rather than reporting the real incompatibility.
Why do $ref resolutions fail or loop?
References are JSON Pointers, so the fragment after the hash is slash-delimited with ~1 escaping a literal slash and ~0 escaping a tilde — a path key such as /users/{id} used inside a pointer must be escaped. External refs pull in other files or URLs, which introduces relative path resolution and, for remote documents, CORS. Recursive schemas are legal and common for tree structures; a resolver that expands eagerly rather than lazily will hang on them, and a naive code generator will emit infinitely nested types.
How do allOf, oneOf, and anyOf actually differ?
allOf requires the instance to satisfy every subschema, which people use for inheritance even though it is really intersection — conflicting constraints produce a schema nothing can satisfy. oneOf requires exactly one match, so overlapping subschemas make otherwise valid payloads fail. anyOf requires at least one. Discriminated unions need a discriminator with an explicit property name and mapping; without it, validators must try every branch, and error messages become a list of failures across all of them rather than one useful message.
Does the spec's security section tell me how to authenticate?
It tells you the scheme names and where credentials go — header, query, cookie, or an OAuth2 flow with its URLs and scopes. It does not tell you how to obtain a credential, and the top-level security block is only a default that individual operations override, including with an empty array to mark a public endpoint. Read the operation-level requirement, not the global one. Note also that an array of requirement objects is OR, while multiple keys inside one object are AND.
Why do generated clients diverge from the live API?
Hand-maintained specs drift: a field added to the response is not added to the schema, nullable is omitted where the database column allows null, and additionalProperties defaults to permitting anything, so a strict generated model breaks on the first unexpected key. Undocumented error shapes are the most common gap — specs cover 200 thoroughly and 4xx barely. Contract testing that replays real responses against the schema catches this; reading the document alone does not.