How to convert an openapi yaml specification to json
- Step 1Bundle a multi-file spec first — If your spec splits schemas across files with
$ref: './schemas/*.yaml', bundle it into a single file withswagger-cli bundleor@redocly/cli bundlebefore converting — external refs are not resolved here. - Step 2Paste the spec — Copy your
openapi.yaml/swagger.yamlcontents, or drop the file. The top of the document should beopenapi: 3.x.xorswagger: "2.0". Keep Multi-document YAML (---) off — a spec is a single document. - Step 3Pick an indent — Minified for a compact
openapi.jsonartifact you check into a repo or pass to a generator. 2 or 4 spaces for a readable spec to review. - Step 4Convert to JSON — Click Convert to JSON. The output is a single self-contained object. YAML anchors for reusable schemas are resolved; internal
$refs are preserved as strings. - Step 5Import or generate — Save as
openapi.json. Import into Postman via File → Import → OpenAPI, or runopenapi-generator-cli generate -i openapi.json -g typescript-axios -o ./src/api. - Step 6Validate the converted JSON — Run the JSON through an OpenAPI validator like Spectral, or paste it into the JSON Validator to confirm no structural issue crept in during conversion.
How spec features convert
OpenAPI-specific constructs and what the converter does with each.
| Spec feature | Behavior | Note |
|---|---|---|
Internal $ref: '#/...' | Preserved verbatim | Your generator/validator resolves these |
External $ref: './x.yaml' | Preserved verbatim (not resolved) | Bundle the spec first if you need a single self-contained file |
YAML anchor &S / *S | Resolved and expanded inline | Output has no aliases left |
x- vendor extensions | Preserved unchanged | e.g. x-amazon-apigateway-*, x-tagGroups |
openapi: 3.0.0 | string preserved if quoted | See version-string note below |
enum: [active, archived] | JSON array of strings | Values preserved exactly |
Version-string coercion to watch
js-yaml 4.1.1 (YAML 1.2 core schema). Bare version numbers can coerce — quote them as the spec recommends.
| YAML | JSON out | Note |
|---|---|---|
swagger: "2.0" | "2.0" | Quoted → correct string |
swagger: 2.0 | 2 | Unquoted float → trailing zero lost; invalid spec |
openapi: 3.0.0 | "3.0.0" | Three-part version is a string either way |
version: 1.10 | 1.1 | Quote API info.version ("1.10") to keep it |
example: 0123 | 123 | Quote IDs with leading zeros |
Cookbook
Spec snippets and the JSON the converter produces. The theme: bundle external refs first, and quote version strings.
A minimal OpenAPI 3 spec to JSON
ExampleThe whole document becomes one self-contained JSON object, ready for Postman or a generator.
Input (openapi.yaml):
openapi: 3.0.3
info:
title: Pet API
version: "1.0.0"
paths:
/pets:
get:
responses:
"200": { description: OK }
Output JSON (2-space):
{
"openapi": "3.0.3",
"info": { "title": "Pet API", "version": "1.0.0" },
"paths": { "/pets": { "get": { "responses": { "200": { "description": "OK" } } } } }
}Internal $ref preserved; external $ref needs bundling
ExampleInternal component refs survive as strings (correct). External file refs are also left literal — bundle first so the JSON is self-contained.
Input:
components:
schemas:
Pet:
$ref: '#/components/schemas/Animal' // internal — kept
User:
$ref: './schemas/user.yaml' // external — kept literal
Output JSON:
{ "components": { "schemas": {
"Pet": { "$ref": "#/components/schemas/Animal" },
"User": { "$ref": "./schemas/user.yaml" }
} } }
Fix for external refs: swagger-cli bundle openapi.yaml > bundled.yaml,
then convert bundled.yaml.Swagger 2.0 version coercion trap
ExampleAn unquoted swagger: 2.0 becomes the number 2, which is an invalid spec. Always quote the version.
Input (WRONG):
swagger: 2.0
Output JSON:
{ "swagger": 2 } // invalid — tooling rejects it
Input (RIGHT):
swagger: "2.0"
Output JSON:
{ "swagger": "2.0" } // valid Swagger 2.0 markerShared schema via a YAML anchor is expanded
ExampleHand-written specs sometimes DRY up a repeated schema with an anchor. The converter inlines it — no aliases remain, so the JSON is fully self-contained.
Input:
components:
schemas:
Timestamps: &ts
type: object
properties:
createdAt: { type: string, format: date-time }
Post:
allOf:
- *ts
- type: object
properties: { title: { type: string } }
Output JSON: the *ts alias is replaced inline with the full
Timestamps object inside Post.allOf — no anchors left.x- extensions preserved for Redoc / API Gateway
ExampleVendor extensions pass through unchanged so the platform that reads them still works after conversion.
Input:
x-tagGroups:
- name: Core
tags: [pets, users]
paths:
/pets:
x-amazon-apigateway-integration:
type: aws_proxy
Output JSON (extensions untouched):
{
"x-tagGroups": [ { "name": "Core", "tags": ["pets", "users"] } ],
"paths": { "/pets": { "x-amazon-apigateway-integration": { "type": "aws_proxy" } } }
}Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
External `$ref` to another file
Not resolved$ref: './schemas/user.yaml' is preserved as a literal string, not inlined — $ref is an OpenAPI feature, not a YAML one, and there is no filesystem in the browser to read the other file. Bundle the spec into one file with swagger-cli bundle or @redocly/cli bundle before converting if you need a self-contained JSON.
Unquoted `swagger: 2.0`
Invalid specUnquoted 2.0 is a float and serializes to 2, which is not a valid Swagger version marker — importers reject it. Always write swagger: "2.0". Same applies to a numeric info.version like 1.10, which becomes 1.1; quote it.
Tab indentation in the spec
Tab errorA tab in indentation throws tab characters must not be used in indentation with line/column. OpenAPI tooling would reject tabs too. Re-indent with spaces.
Duplicate path or duplicate operation key
Duplicate key errorTwo identical path keys, or two get: operations under one path, throw duplicated mapping key. The parser rejects rather than keeping the last — a good thing, since a duplicate path in a spec is a real bug. Fix it before converting.
Status code keys like `200`
Quote recommendedResponse codes should be quoted strings ("200") in OpenAPI. An unquoted 200: parses as a numeric key in YAML, and while js-yaml emits it as a JSON object key (always a string in JSON), some specs rely on the exact string form — quoting avoids ambiguity, especially for "default" alongside numeric codes.
Empty or comments-only spec file
Undefined outputAn empty file parses to undefined, outputting the literal undefined rather than {}. Paste a real spec starting with openapi: or swagger:.
Custom YAML tag accidentally added
Unknown tag errorSpecs have no custom YAML tags, but a stray !-prefixed value throws unknown tag. Only standard YAML 1.2 tags are recognised. Remove or quote the tagged value.
Very large example integer (e.g. a 64-bit ID)
Precision lossAn example: 9007199254740993 (above 2^53−1) loses precision through the JS number type. For 64-bit ID examples, quote them as strings in the spec so they round-trip exactly.
Spec over the free 2 MB limit
Upgrade requiredLarge bundled specs (every schema inlined) can exceed the 2 MB free-tier limit. Pro raises it to 100 MB. Alternatively, validate against the un-bundled spec and only bundle for the final artifact.
Internal `$ref` you wanted inlined
By designInternal #/components/... refs are preserved, not dereferenced — that is the correct, portable form, and Postman / generators resolve them. If you specifically need a fully-dereferenced spec, run a deref tool (e.g. @redocly/cli bundle --dereferenced) before converting.
Frequently asked questions
Are `$ref` references resolved during conversion?
No. Internal refs (#/components/schemas/User) are preserved verbatim — that is the correct, portable form and your tooling resolves them. External file refs (./schemas/user.yaml) are also left literal, because there is no filesystem in the browser. Bundle multi-file specs with swagger-cli bundle first if you need one self-contained JSON.
Will the JSON import into Postman?
Yes. Save the output as openapi.json and use Postman's File → Import → OpenAPI. The converter produces a single self-contained object (anchors resolved), which is exactly what Postman's importer expects. Internal $refs are resolved by Postman during import.
Why did my `swagger: 2.0` become the number 2?
Unquoted 2.0 is a YAML float, and the trailing zero is dropped, leaving 2 — which is not a valid Swagger version marker. Always quote it: swagger: "2.0". The same trap hits a numeric info.version like 1.10 (becomes 1.1).
Are my x- vendor extensions kept?
Yes. Every x--prefixed field — x-amazon-apigateway-integration, Redocly's x-tagGroups, Stoplight metadata — is preserved unchanged. The converter does not strip or rewrite extensions, so the platform that reads them still works on the JSON output.
Does it validate the OpenAPI spec?
No — it only converts YAML to JSON. It will not tell you if a required field is missing or a $ref is broken. After converting, run the JSON through Spectral or another OpenAPI linter, or use the JSON Validator for structural checks.
Will the output work with AWS API Gateway import?
API Gateway accepts OpenAPI 3.0 JSON. The converter produces valid JSON, but AWS has its own requirements around x-amazon-apigateway-* extensions — those are preserved by the converter but you must ensure they are present and correct for AWS. Validate against AWS's supported subset before importing.
Is my API spec uploaded to JAD Apps?
No. Conversion runs entirely in your browser with js-yaml. Internal endpoint paths, auth schemes, and proprietary schema shapes stay on your machine — nothing is transmitted to JAD Apps servers.
How do I make a fully self-contained JSON spec?
Bundle external file refs first with swagger-cli bundle openapi.yaml or @redocly/cli bundle, which inlines them into a single YAML document. Convert that bundled file here. Internal #/components refs remain as refs (the portable form); use a dereference flag if you need them inlined too.
Are YAML anchors in my spec resolved?
Yes. js-yaml expands anchors (&name / *name) and merge keys (<<: *name) during parsing, so a schema shared via an anchor is inlined everywhere it is referenced. The resulting JSON has no aliases — it is self-contained.
Should response codes be quoted in my spec?
Yes, OpenAPI treats status codes as strings ("200", "default"). YAML will accept an unquoted 200: and it becomes a string key in JSON (JSON object keys are always strings), but quoting in the source avoids any ambiguity and matches the spec — especially when mixing numeric codes with "default".
Can I diff two API spec versions?
Yes. Convert both versions to JSON, then run the JSON Diff tool to see exactly which paths, parameters, or schemas changed between releases — far more readable than a raw YAML diff sensitive to key ordering and formatting.
Can I convert the JSON spec back to YAML?
Yes, with the inverse JSON to YAML tool. Teams that maintain a YAML source of truth but receive a JSON spec from a vendor often convert it back to YAML for a cleaner Git diff and review.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.