Convert YAML to JSON Without Losing Config Types

YAML is convenient for configuration, but its compact syntax can hide a type mistake. When a deployment rejects a manifest, converting it to JSON exposes whether a value is a string, number, boolean, or nested object. Use the YAML Formatter for the conversion, then the JSON Formatter if you need to inspect the result further.

Start with an explicitly typed ConfigMap

Paste this into YAML-to-JSON mode:

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-settings
data:
  PORT: "8080"
  FEATURE_ENABLED: "false"

The output is:

{
  "apiVersion": "v1",
  "kind": "ConfigMap",
  "metadata": {
    "name": "api-settings"
  },
  "data": {
    "PORT": "8080",
    "FEATURE_ENABLED": "false"
  }
}

The quotes are deliberate. Kubernetes requires ConfigMap data values to be strings; the ConfigMap documentation explains its data and binaryData fields. A configuration value that looks like a port number is still text in this context.

See what removing quotes changes

Now convert this smaller fragment:

PORT: 8080
FEATURE_ENABLED: false

The result contains a number and a boolean:

{
  "PORT": 8080,
  "FEATURE_ENABLED": false
}

That is valid YAML and valid JSON, but it is the wrong shape for ConfigMap data. A successful syntax check does not validate the Kubernetes API schema. Keep the quotes, then validate the complete manifest against your target cluster’s schema before deployment.

Convert back and compare values

Put the first JSON result into JSON-to-YAML mode. The tool produces a two-space-indented document and preserves the two string values. Quote style and layout may change, so compare the parsed values rather than expecting byte-for-byte equality with the original text.

This is useful when reviewing generated configuration: convert, inspect the types, correct the source, and confirm that the corrected YAML parses to the intended object. For environment-file workflows, the Env Converter is a more direct starting point.

Formatting is not a lossless edit

ByteKiln uses the installed js-yaml 4.x parser and dumper. Formatting parses the document into JavaScript values and writes those values back as YAML. Comments, original whitespace, and the original spelling of anchors are not preserved. Conversion to JSON expands aliases into values; JSON has no equivalent syntax for YAML comments or anchors.

A file with several documents separated by ---, such as a Kubernetes manifest with a Service and a Deployment, is handled document by document: Format keeps the --- separators, and YAML to JSON returns a JSON array with one element per document. Duplicate mapping keys are rejected rather than silently choosing one value. Custom application tags can also be rejected by the default loader.

JavaScript numbers have finite integer precision. Keep identifiers and large numeric strings quoted when exact digits matter, and avoid using this conversion as a lossless archive for arbitrary YAML types. A timestamp may also become a JavaScript date and serialize differently in JSON. The js-yaml 4.x documentation describes the loader and dumper options behind these behaviors.

The practical check is small: use an explicit example, inspect the JSON types, and validate against the system that will consume the configuration. Making a file prettier cannot establish that the deployment will accept it.