Edit OpenAPI 3.x specs in YAML or JSON with live validation, Swagger UI preview, and endpoint listing.
An OpenAPI description can be difficult to review as raw YAML or JSON alone. This editor checks an OpenAPI 3.x document while you edit it, renders the declared operations in a Swagger UI preview, and collects them into an endpoint listing. The common surprise is that successful validation confirms the description, not the deployed API. It does not establish that a server is reachable or that its responses match the contract. Editing and validation occur in the browser, so the pasted description is not uploaded.
A concrete input and expected output from the current implementation.
Input
openapi: 3.0.3
info:
title: Ping API
version: 1.0.0
paths:
/ping:
get:
summary: Ping
responses:
'200':
description: OK Expected output
No validation errors. Endpoint listing: GET /ping. Swagger UI preview: GET /ping, summary Ping, with documented response 200 and description OK.
The document supplies the required OpenAPI version, API information, and paths object. It declares exactly one operation, GET on /ping, whose responses object contains one documented response: status code 200 with the description OK.
Paste an OpenAPI 3.x description as YAML or JSON. As the source changes, the editor validates its structure and reports detected problems, such as malformed source or incorrectly shaped OpenAPI fields. Validation is governed by the version named in the top-level openapi field, so that declaration should match the OpenAPI version whose rules the document follows.
Operations declared under paths are presented as HTTP method and path combinations, such as GET /ping. The Swagger UI preview interprets the same description to display summaries, parameters, request bodies, responses, and schemas that are present in the document. Both views describe the contract as written; they do not discover routes from application code or from a running server.
No. Validation evaluates the OpenAPI description, while service behavior is a separate concern. A document can be structurally valid even when its server URL is unreachable, an implemented route is missing, authentication fails, or actual response bodies differ from their declared schemas. Runtime testing or contract testing is needed to establish those facts.
Yes. The editor accepts OpenAPI 3.x descriptions written in either YAML or JSON. Both forms must represent the same required OpenAPI objects, including the top-level openapi, info, and paths fields. Changing the serialization format does not change the documented operations or responses, although syntax errors and scalar typing mistakes can differ between YAML and JSON.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Format, validate, and beautify JSON with syntax highlighting and error detection.
Encode text or files to Base64 and decode Base64 strings back to their original form.
Format and indent SQL queries for better readability across all major dialects.
Convert HTML markup into clean Markdown syntax with support for tables and lists.
Write Markdown and see the rendered HTML output in real time with live preview.
Visualize unified diffs and patch files with color-coded additions and deletions.