YAML to JSON Converter

Example Input

id: 1
name: Priya Singh
email: priya@learnhubly.com
isActive: true
score: 98.5
tags:
  - developer
  - admin
profile:
  bio: Principal Software Engineer
  skills:
    - Go
    - React
    - TypeScript
deletedAt: null

Example Output

{
  "id": 1,
  "name": "Priya Singh",
  "email": "priya@learnhubly.com",
  "isActive": true,
  "score": 98.5,
  "tags": [
    "developer",
    "admin"
  ],
  "profile": {
    "bio": "Principal Software Engineer",
    "skills": [
      "Go",
      "React",
      "TypeScript"
    ]
  },
  "deletedAt": null
}

Does it handle YAML anchors?

Yes. YAML anchors (&name) and aliases (*name) are fully resolved during conversion. An anchor defines a named block of YAML content, and each alias is a reference to that block. In the JSON output, every alias is replaced with the actual content of the anchor at that position — JSON has no equivalent of references or reuse, so the content must be fully duplicated at each reference point. If a Docker Compose file uses anchor-based extension fields to share configuration between services, the JSON output will have the complete configuration at each service rather than the anchor reference. This makes the JSON larger than the YAML but fully self-contained.

What happens to YAML comments during conversion?

All comments are dropped. JSON has no comment syntax, so YAML comments — which start with # and can appear on their own line or at the end of a line — have no representation in JSON. This is expected and unavoidable, not a limitation of this tool specifically. If you are converting YAML that has important comments (explaining why a value is set, documenting version requirements, noting TODOs), save the original YAML file as your source of truth and add corresponding documentation to wherever the JSON is used.

Does it support multi-document YAML files?

Yes. YAML files can contain multiple documents separated by --- (three dashes on their own line). Kubernetes manifest bundles often use this pattern — a single .yaml file with a Deployment and a Service separated by ---. The converter processes each document and outputs a JSON array where each element is the parsed content of one document. If the YAML has a single document (no --- separator), the output is a single JSON object or array, not wrapped in an outer array.

Why does YAML type conversion matter for the JSON output?

YAML automatically converts unquoted scalar values to their inferred types. The unquoted value true becomes boolean true, 42 becomes integer, 3.14 becomes float, and null or ~ become JSON null. These are reflected in the JSON output — the JSON will have boolean true rather than the string 'true', integer 42 rather than '42'. This is usually what you want, but it can be surprising when a YAML value like a version string '1.0' is stored unquoted (1.0) and becomes a float in JSON rather than the string '1.0'. Quote values in YAML that should remain strings regardless of whether they look like numbers or booleans.

How do I convert YAML to JSON in the command line without a browser?

Several options. With yq (the YAML command-line processor): yq -o=json input.yaml > output.json. With Python (built-in yaml and json modules): python3 -c 'import sys, yaml, json; print(json.dumps(yaml.safe_load(sys.stdin), indent=2))' < input.yaml. With Ruby: ruby -ryaml -rjson -e 'puts JSON.pretty_generate(YAML.safe_load(STDIN))' < input.yaml. With Node.js and the js-yaml package: node -e "const yaml=require('js-yaml');const fs=require('fs');console.log(JSON.stringify(yaml.load(fs.readFileSync('/dev/stdin','utf8')),null,2))". For one-off conversions in the browser, this tool is faster. For automated pipelines and scripting, the command-line approach is more appropriate.

Can I convert a Kubernetes manifest bundle with multiple resources to JSON?

Yes — a Kubernetes manifest file with multiple resources separated by --- (Deployment + Service + ConfigMap in one file) produces a JSON array with three elements, one per resource. Each element is the full JSON representation of one Kubernetes resource including apiVersion, kind, metadata, and spec. This JSON array can be used with tools that process JSON arrays, or you can extract individual resources with jq: jq '.[0]' bundle.json for the first resource, jq '.[] | select(.kind == "Deployment")' bundle.json to extract only the Deployment resource by kind.

Is the JSON output minified or pretty-printed?

The output is pretty-printed with 2-space indentation by default, making it immediately readable. Pretty-printed JSON is what you want for pasting into documentation, reading in a text editor, or copying into a REST API client like Postman that renders JSON. If you need minified JSON (no whitespace, single line) for embedding in a curl command or for a system that does not handle formatted JSON well, copy the output and run it through a JSON minifier, or use the JSON Formatter tool to toggle between formatted and minified output.

Why would I use YAML to JSON instead of just working with YAML directly?

A few concrete reasons. jq only processes JSON — if you want to query YAML data with jq, you must convert first. REST APIs accept JSON request bodies, not YAML — if your configuration source is YAML and you need to post it to an API, convert first. Terraform's external data source outputs JSON and expects JSON — integrating YAML-sourced data requires conversion. Programmatic comparison of two configurations is easier in JSON where you can use JSON diff tools rather than YAML diff tools that have to account for semantically equivalent but syntactically different representations. And inspecting what Kubernetes actually stored for a resource (kubectl get -o json) gives JSON — comparing it to your YAML manifest converted to JSON reveals configuration drift clearly.