How to Convert Between JSON and YAML

Convert one document and inspect scalar types

Choose the required direction in Converters. The local YAML reader uses js-yaml load for one document. A stream containing multiple documents separated by --- is rejected; split it deliberately or use a separate multi-document parser when that is the actual contract.

The example below preserves NO as text and enabled as a boolean under the converter’s YAML 1.2-style scalar rules. Quoting intended strings is still a useful way to make intent clear across consumers with different schemas.

YAML:
country: "NO"
enabled: true

JSON:
{"country":"NO","enabled":true}

Not supported as one input:
a: 1
---
b: 2

Preserve meaning rather than source appearance

Check nulls, booleans, numeric-looking strings, dates and long numeric identifiers after conversion. YAML tags and non-JSON values may not have an equivalent JSON representation. Do not assume that parser acceptance proves compatibility with Kubernetes, a CI service or another consumer.

Converting through parsed values drops comments and can change quoting and layout. JavaScript Number precision also applies. A parse-and-reserialize operation is unsuitable when exact source bytes or signatures must stay unchanged.

Test the target consumer safely

Compare representative parsed values on a round trip and validate against the target application’s schema. Use a syntax/schema or dry-run facility where available before applying configuration to a real environment.

Do not put a production apply command in the verification step merely to see whether a parser error goes away. Stop when the intended document count, key/value types and target schema are confirmed. Retain the original for review and rollback.

References

Use the linked specifications and product documentation to check behavior in your own environment.