YAML to JSON: Preserve Strings, Booleans and Leading Zeros

When configuration is also an API input, a readable conversion is not enough. A customer identifier can look numeric while the API requires a string. Start with the fixture below in YAML to JSON. The customer_id must remain the string '007', retries must be a number, enabled must be a boolean, and unset must be null. The empty value is a separate empty string.

Inspect the converted JSON before using it in a request. Keeping leading zeros is a contract requirement for this fixture, not a formatting preference. Use JSON Validator for syntax and JSON Schema Validator when you also need to enforce the expected field types.

The expected data is shown below. Check values and types, not whitespace or object-key order. Quotes around customer_id, empty and label matter; pretty indentation does not prove those types. A visually similar value such as 7 cannot recover the original identifier '007'.

For identifiers that exceed JavaScript's safe integer range, use strings in the source contract. A browser conversion using JavaScript numbers cannot guarantee exact preservation of arbitrary large integers. Verify timestamps, identifiers and monetary representations against your consumer's schema before migrating configuration.

The site uses the yaml library's default YAML 1.2 parsing. Other configuration consumers may apply a different YAML version or schema. In particular, do not assume every parser interprets unquoted yes, no, on and off identically. Quote a value when the contract says it is text, then test with the parser used by the target application.

Keep this converter's input to one document with JSON-compatible data. A YAML stream containing multiple documents needs an explicit policy for selecting or collecting documents; this tool does not silently combine them. Custom tags, non-string mapping keys and cyclic aliases also need decisions beyond a routine JSON conversion.

A configuration file with two retries keys is ambiguous to a reader even if another parser silently chooses the last one. The site's YAML parser rejects duplicate keys. Remove the ambiguity in the original configuration rather than relying on a conversion to choose your intended value.

The fixture below is intentionally invalid and should produce an error. Include it alongside the successful fixture when checking a migration. An explicit failure prevents a changed retry limit from becoming an unnoticed deployment difference.

Take the successful JSON output to JSON to YAML, then convert that YAML back to JSON. Compare the parsed values and types with the first result. This checks the conversion pair for your fixture. It does not prove that every possible document or your application's business rules are preserved.

Comments, original quote style, indentation and anchor notation are not part of a JSON value. A JSON-to-YAML round trip cannot reconstruct that editing history. Keep the original configuration in version control and compare the data before replacing it. Use a sanitized fixture when sharing a reproducible conversion problem.