Docify

YAML to JSON

Convert YAML to JSON and JSON to YAML in your browser. Uses js-yaml CORE_SCHEMA (YAML 1.2 Core). Single document only.

Docify's YAML tool converts one document in your browser with js-yaml 5. YAML → JSON calls load with CORE_SCHEMA (YAML 1.2 Core), then JSON.stringify with 2-space indent. JSON → YAML calls JSON.parse, then dump with the same schema, 2-space indent, unlimited line width, and noRefs. Click Convert to process the input. The example shows name: Docify, a tools sequence of json and yaml, count: 2, and enabled: true; clicking Convert produces the matching 2-space JSON {"name":"Docify","tools":["json","yaml"],"count":2,"enabled":true}. In JSON → YAML mode, clicking Convert on that JSON produces the same YAML via dump. Empty streams and duplicate keys throw. A leading --- on one document converts. A second document after --- throws (“expected a single document in the stream, but found more”). This page does not call loadAll. A tab used as block indentation throws (YAML 1.2.2 §6.1 — s-indent is spaces only). Write two spaces. A tab inside a scalar is content and is kept. Comments are dropped. yes / NO stay strings. A leading-zero integer such as 010 is decimal 10 (YAML 1.2.2 §10.3.2). Octal needs the 0o prefix (0o10 → 8). 1:30:00 and 0b10 stay strings. An underscore integer such as 1_000 stays a string (YAML 1.2.2 §10.3.2). Write 1000. YAML 1.1 !!int ignored _. Quoted "010" stays a string. A Core integer such as 9007199254740993 becomes {"value":9007199254740992} (IEEE-754; YAML 1.2.2 §10.2.1.3). Exact integers end at 9007199254740991 (2^53 − 1). Quoted "9007199254740993" stays the exact string. This page does not parse integers as BigInt. ~, null, and an empty mapping value become JSON null (YAML 1.2.2 §10.3.2). Write "" for an empty string. A date-only value such as 2026-08-20 stays a string (YAML 1.2.2 §10.3.2 dropped !!timestamp). YAML 1.1 !!timestamp resolved it as 00:00:00Z. An explicit !!timestamp tag throws. A leading-dot or trailing-dot float such as .5 or 1. becomes 0.5 or 1 (YAML 1.2.2 §10.3.2). 1e2 is 100. JSON.parse rejects those incomplete-looking decimals. Write 0.5 or 1.0 for JSON-legal source. YAML 1.1 !!float ignored _ and parsed sexagesimal 190:20:30.15. Core keeps those as strings. A Core boolean such as True or FALSE becomes JSON true or false (YAML 1.2.2 §10.3.2). JSON.parse rejects those capitalizations; write true or false. Quoted "True" stays a string. yes / NO stay strings. A literal | block such as note: | with indented hello / world becomes {"note":"hello\nworld\n"} (YAML 1.2.2 §8.1.2 clip). |- strips that final newline. A folded > block becomes {"note":"hello world\n"} (§8.1.3). dump may rewrite > as |. A mapping key such as 1: or true: becomes a JSON string name (YAML 1.2.2 §3.2.1.1; RFC 8259 §4). 1: one is {"1":"one"}. true: yes is {"true":"yes"}. JSON has no numeric-key production. A sequence or mapping key throws. Anchors and aliases are Core (YAML 1.2.2 §3.2.2.2 / §6.9.2 / §7.1). item: &id / copy: *id becomes two JSON copies. <<: *base keeps a "<<" member (YAML 1.2.0 removed merge <<). {"app":{"<<":{"host":"localhost"},"name":"docify"}}. An explicit !!merge tag throws. An explicit !!str 010 stays the string "010" (YAML 1.2.2 §6.9.1 / §10.3.1). !!int 010 is still 10. !!bool yes throws. A non-specific ! on a scalar also stays a string. !!binary / !!timestamp throw. JSON → YAML dump quotes a string that would resolve as a Core int, bool, null, or float if left plain (YAML 1.2.2 §7.3.2 / §10.3.2). {"value":"010"} becomes value: '010'. {"value":"true"} becomes value: 'true'. {"value":"yes"} stays value: yes. Not YAML 1.1, not Kubernetes merge, not a linter. This page does not Prettify, Minify, or Validate a JSON document. For JSON formatting, see /json-formatter/. Nothing is uploaded.

YAML
JSON output

How it works

  1. Click Convert to run the conversion. The example shows name: Docify, a tools sequence of json and yaml, count: 2, and enabled: true. Clicking Convert produces the matching 2-space JSON {"name":"Docify","tools":["json","yaml"],"count":2,"enabled":true}. In JSON → YAML mode, clicking Convert on that JSON produces the same YAML via dump. Copy writes the output. Nothing is uploaded.
  2. YAML → JSON uses load with CORE_SCHEMA, then JSON.stringify(..., null, 2). JSON → YAML uses JSON.parse, then dump with indent: 2, lineWidth: -1, noRefs: true, and the same schema.
  3. One document only. Empty input throws. A leading --- on a single mapping converts. A second document after --- throws “expected a single document in the stream, but found more”. A trailing --- after a finished document starts an empty second document and throws too. This page does not call loadAll. Duplicate keys throw. Comments are dropped. Anchors expand to copies. .inf / .nan become JSON null.
  4. Block indentation is spaces only (YAML 1.2.2 §6.1). A nested mapping that indents the next key with a tab throws “tab characters must not be used in indentation”. Two spaces convert. A tab inside a scalar is content. dump writes 2-space indent, never tabs. This page does not expand tabs.
  5. Core integers are decimal [-+]? [0-9]+, octal 0o [0-7]+, and hex 0x [0-9a-fA-F]+ (YAML 1.2.2 §10.3.2). 010 is 10; 0o10 is 8; 0777 is 777. 1:30:00 and 0b10 stay strings. An underscore form such as 1_000 stays a string; write 1000. YAML 1.1 !!int ignored _. Quoted "010" stays a string. This is not YAML 1.1 leading-zero octal.
  6. Core integers are constructed with parseInt (IEEE-754 Number; YAML 1.2.2 §10.2.1.3). Exact integers end at Number.MAX_SAFE_INTEGER, 9007199254740991 (2^53 − 1). value: 9007199254740993 becomes {"value":9007199254740992}. value: !!int 9007199254740993 and hex 0x20000000000001 do the same. JSON.stringify then writes that even value. Quoted "9007199254740993" stays the exact string. This page does not parse integers as BigInt. This is the host Number, not a YAML 1.1 vs 1.2 type change.
  7. Core nulls are null | Null | NULL | ~ and an empty scalar (YAML 1.2.2 §10.3.2 / §7.2). value: ~, value: null, and value: with nothing after the colon become {"value":null}. Write value: "" for {"value":""}. Quoted "null" and "~" stay strings. none and nil stay strings. An empty input stream throws “expected a document”. This is not the .inf → JSON null stringify case.
  8. Core has no timestamp type (YAML 1.2.2 §10.3.2). date: 2026-08-20 becomes {"date":"2026-08-20"}. date: 2001-12-15T02:59:43.1Z stays that string. YAML 1.1 !!timestamp (yaml.org/type/timestamp.html) resolved a date-only value as 00:00:00Z. An explicit !!timestamp tag throws “unknown scalar tag !<tag:yaml.org,2002:timestamp>”. Quoted "2026-08-20" stays a string. This is not YAML 1.1 !!timestamp.
  9. Core floats are [-+]? ( \. [0-9]+ | [0-9]+ ( \. [0-9]* )? ) ( [eE] [-+]? [0-9]+ )? (YAML 1.2.2 §10.3.2). value: .5 becomes {"value":0.5}. value: 1. becomes {"value":1}. value: 1e2 becomes {"value":100}. The spec example lists 0., .5, +12e03, and -2E+05. RFC 8259 / ECMA-404 reject .5 and 1.. Write 0.5 or 1.0. Quoted ".5" stays a string. YAML 1.1 !!float (yaml.org/type/float.html) required a decimal point, ignored _, and parsed sexagesimal 190:20:30.15. Core keeps 685_230.15 and that colon form as strings. This is not the .inf → JSON null stringify case.
  10. Core booleans are true | True | TRUE | false | False | FALSE (YAML 1.2.2 §10.3.2). enabled: True becomes {"enabled":true}. enabled: FALSE becomes {"enabled":false}. RFC 8259 / ECMA-404 allow only lowercase true and false, so JSON.parse("True") throws. Write true or false in JSON. Quoted "True" stays a string. Mixed-case TruE stays a string. yes, NO, and on stay strings. YAML 1.1 !!bool (yaml.org/type/bool.html) also accepted those six plus yes/no/on/off/y/n. This is not a Python-literal parser.
  11. Block scalars are presentation (YAML 1.2.2 §8.1). note: | with indented hello / world becomes {"note":"hello\nworld\n"} (literal, clip). note: |- is {"note":"hello\nworld"} (strip). note: > is {"note":"hello world\n"} (folded, clip). note: >- is {"note":"hello world"}. |+ / >+ keep extra trailing blank lines. dump may rewrite > as | or a plain scalar. This is not a YAML 1.1 vs 1.2 type change.
  12. Mapping keys may be any node (YAML 1.2.2 §3.2.1.1). RFC 8259 §4 / ECMA-404 require JSON member names to be strings. 1: one becomes {"1":"one"}. true: yes becomes {"true":"yes"}. 010: padded becomes {"10":"padded"} because the key is the Core integer 10, then ToString. ~: missing becomes {"null":"missing"}. A sequence or mapping key throws “object-based map does not support complex keys”. 1: and "1": in the same mapping throw as a duplicate key. JSON.parse('{1:"one"}') throws. This is not a YAML 1.1 vs 1.2 type change.
  13. Anchors and aliases are Core (YAML 1.2.2 §3.2.2.2 / §6.9.2 / §7.1). item: &id with name: Docify and copy: *id becomes {"item":{"name":"Docify"},"copy":{"name":"Docify"}}. YAML 1.2.0 (2009-07-21) removed the merge << and value = keys. <<: *base keeps a "<<" member whose value is the expanded alias: {"app":{"<<":{"host":"localhost","port":80},"name":"docify"}}. <<: [*a, *b] becomes a JSON array under "<<". Quoted "<<": extra is already that string name. =: stays "=". An explicit !!merge tag throws “unknown scalar tag !<tag:yaml.org,2002:merge>”. This is not Kubernetes merge.
  14. !! is the secondary tag handle (YAML 1.2.2 §6.8.2.1 / §6.9.1). The default prefix is tag:yaml.org,2002:. Core §10.3.1 accepts !!str, !!int, !!bool, !!null, !!float, !!seq, and !!map. value: !!str 010 becomes {"value":"010"}. value: !!int 010 is still {"value":10}. value: !!str true is {"value":"true"}. value: !!bool yes throws “cannot resolve a node with !<tag:yaml.org,2002:bool> explicit tag”. value: ! 010 (non-specific !) also becomes {"value":"010"}. Quoted "010" is already that string. !!binary, !!timestamp, !!merge, !!set, and !!omap throw “unknown scalar tag”. This is not a YAML 1.1 schema.
  15. JSON → YAML dump quotes a string that would resolve as a Core int, bool, null, or float if left plain (YAML 1.2.2 §7.3.2 / §10.3.2). dump uses single quotes by default; this page does not set forceQuotes. {"value":"010"} becomes value: '010'. {"value":"true"} becomes value: 'true'. {"value":"null"} becomes value: 'null'. {"value":"yes"} stays value: yes because Core keeps yes as a string. {"value":"2026-08-20"} stays unquoted. {"1":"one"} becomes '1': one. Unquoted value: 010 still becomes {"value":10}. This is presentation, not a YAML 1.1 vs 1.2 type change.
  16. This is not YAML 1.1 (no Norway-problem booleans, no leading-zero octal), not !!merge, not a comment- preserving pretty-printer, and not a Kubernetes or JSON Schema validator. This page does not Prettify, Minify, or Validate a JSON document. For JSON formatting, see /json-formatter/.

YAML to JSON in Python and Node

The snippets below parse one YAML document and write 2-space JSON, the same single-document flow this page uses. They are not Kubernetes validators and they do not keep comments. For the dialect this converter actually runs, see YAML 1.2 Core vs 1.1.

Node.js with js-yaml 5

js-yaml 5 load uses CORE_SCHEMA (YAML 1.2 Core) by default. Passing the schema keeps the call aligned with this page. Empty input and a second document after --- throw. Then JSON.stringify writes the JSON:

import { load, CORE_SCHEMA } from 'js-yaml';

const yamlText = `name: Docify
count: 2
enabled: true`;

const data = load(yamlText, { schema: CORE_SCHEMA });
const json = JSON.stringify(data, null, 2);

Python with PyYAML (YAML 1.1)

Use yaml.safe_load, not yaml.load, then json.dumps. PyYAML follows YAML 1.1, so it is not the same dialect as this page: unquoted yes / no / on / off become booleans (the Norway problem), and 010 is octal 8. This page keeps those as a string and decimal 10:

import json
import yaml

yaml_text = """
name: Docify
count: 2
enabled: true
"""

data = yaml.safe_load(yaml_text)
print(json.dumps(data, indent=2))

Python with ruamel.yaml (YAML 1.2)

ruamel.yaml defaults to YAML 1.2. typ='safe' plus pure=True uses the pure-Python loader so leading-zero decimals stay decimal, closer to this page's Core schema. The C loader can still treat some values more like YAML 1.1:

import json
from ruamel.yaml import YAML

parser = YAML(typ='safe', pure=True)
data = parser.load("""
name: Docify
count: 2
enabled: true
""")
print(json.dumps(data, indent=2))

JSON to YAML in Node

The reverse direction on this page is JSON.parse then js-yaml 5 dump with the same Core schema, 2-space indent, unlimited line width, and noRefs so duplicate objects are inlined:

import { dump, CORE_SCHEMA } from 'js-yaml';

const data = JSON.parse(jsonText);
const yamlOut = dump(data, {
  indent: 2,
  lineWidth: -1,
  noRefs: true,
  schema: CORE_SCHEMA,
});

YAML to JSON in the shell

There is no POSIX YAML converter. kislyuk yq (a Python wrapper around jq, not the Go mikefarah binary) transcodes YAML to JSON and passes it to jq. On the mapping this page documents, yq . writes the same 2-space JSON Convert writes. The filter can be omitted; yq then uses ., like jq. Homebrew brew install yq typically ships mikefarah/yq (-o json), whose flags fail on this wrapper. pip or Debian python3-yq is kislyuk. yq is not POSIX. For the js-yaml and PyYAML snippets, see YAML to JSON in Python and Node above.

kislyuk yq (Linux / pip)

yq 3.x uses YAML 1.2 implicit resolvers, then jq 1.7 pretty-prints with 2-space indent — the same indent this page uses. JSON → YAML is -y / --yaml-output. JSON input works because YAML treats JSON as a dialect. Confirmed here with kislyuk yq 3.1.0 and jq 1.7:

# YAML → JSON (same 2-space JSON as this page on this mapping)
printf '%s' 'name: Docify
tools:
  - json
  - yaml
count: 2
enabled: true
' | yq .
# {
#   "name": "Docify",
#   "tools": [
#     "json",
#     "yaml"
#   ],
#   "count": 2,
#   "enabled": true
# }

# Compact JSON (this page always pretty-prints)
printf '%s' 'name: Docify
tools:
  - json
  - yaml
count: 2
enabled: true
' | yq -c .
# {"name":"Docify","tools":["json","yaml"],"count":2,"enabled":true}

# JSON → YAML
printf '%s' '{"name":"Docify","tools":["json","yaml"],"count":2,"enabled":true}' | yq -y .
# name: Docify
# tools:
#   - json
#   - yaml
# count: 2
# enabled: true

yq 3.0+ keeps yes / NO / on as strings, matching this page — unlike the PyYAML safe_load card above, which still follows YAML 1.1 bools. PyYAML's int constructor is still YAML 1.1, so 010 becomes 8 in yq; this page writes decimal 10. 0o10 is 8 in both. yq 3.0.2 expands merge <<; this page keeps a "<<" member. A second document after --- prints another JSON value; this page throws. Duplicate keys keep the last value; this page throws. Empty stdin exits 0 with no output; Convert stays disabled until there is text. jq appends a trailing newline after the last }; this page's JSON.stringify does not. .inf writes 1.7976931348623157e+308 (IEEE-754 max); this page writes null. .nan is null in both. A trailing-dot float 1. becomes 1.0 in yq and 1 here. -y defaults to YAML 1.1 output grammar, so {"value":"yes"} becomes value: 'yes'; this page dump writes unquoted value: yes. --yaml-output-grammar-version 1.2 emits that string unquoted. {"value":"010"} is quoted in both. -Y is round-trip annotation, not this converter. python3 -m yq is the same wrapper. Debian yq --version may print 0.0.0; the package here is 3.1.0. mikefarah flags such as -o json and eval fail with usage. macOS Homebrew yq is usually the Go binary; install kislyuk with pip and a jq on PATH. Windows is the same pip plus jq. For YAML 1.2 Core vs 1.1 bools and octal, see YAML 1.2 Core vs 1.1: Norway, Comments, JSON.

FAQ

Does this converter upload my YAML or JSON?
No. All conversion runs in your browser with js-yaml 5 and JSON.parse / JSON.stringify. Nothing is sent to a server.
How does a YAML mapping become JSON?
A YAML mapping becomes a JSON object, and a YAML sequence becomes a JSON array. Nested mappings become nested objects; dash lists become arrays in the same order. YAML to JSON uses js-yaml 5 load with CORE_SCHEMA, then JSON.stringify with 2-space indent. JSON to YAML dumps that JSON back with the same schema. This is not YAML 1.1, not loadAll, and not a comment-preserving pretty-printer. For JSON formatting, see /json-formatter/.
Which YAML dialect does this page parse?
js-yaml 5 load with CORE_SCHEMA — YAML 1.2 Core. true/True/TRUE, false/False/FALSE, and null (and ~) are typed; yes, no, and NO stay strings, so the YAML 1.1 Norway problem does not apply. Dates such as 2026-08-20 stay strings. 010 is decimal 10; octal needs the 0o prefix. Core explicit tags (!!str, !!int, !!bool, !!null, !!float, !!seq, !!map) are accepted. !!merge (<<) is not enabled, so a << key is just a key. !!binary and !!timestamp throw. This is not YAML 1.1, not Kubernetes validation, and not a schema linter.
What does Convert reject or drop?
load accepts one document. Empty input, a whitespace-only stream, and multi-document streams (---) throw. Duplicate mapping keys throw. A tab used as block indentation throws (YAML 1.2.2 §6.1). Comments are discarded. Anchors are expanded into copies. JSON.stringify turns YAML .inf and .nan into null because JSON has no Infinity or NaN. JSON → YAML uses JSON.parse, so comments, trailing commas, and single quotes are rejected.
Why does a tab-indented YAML mapping fail Convert?
YAML 1.2.2 §6.1 (Indentation Spaces) defines block indentation as space characters only (s-indent is s-space). Tab characters must not be used in indentation. js-yaml 5 load with CORE_SCHEMA throws “tab characters must not be used in indentation” for a nested mapping that indents the next key with a tab. Two spaces before that key convert. A tab inside a scalar is content, not indentation, and is kept. A tab between flow tokens is separation (spec 6.2) and is allowed. dump writes 2-space indent, never tabs. This page does not retab or expand tabs. Nothing is uploaded.
Why does a second YAML document after --- fail Convert?
YAML 1.2.2 §9.1 says a stream may contain several documents. --- is c-directives-end (document start), not illegal YAML. js-yaml 5 load accepts one document. A leading --- on a single mapping converts. a: 1 then --- then b: 2 throws “expected a single document in the stream, but found more”. A trailing --- after a finished document starts a second (empty) explicit document and throws too. A document-end ... after one document is fine. --- inside a quoted string or as a mapping value is content, not a second document. Kubernetes-style multi-doc files fail for the same reason. This page does not call loadAll. Convert one document, or split the stream. Nothing is uploaded.
Why does YAML 010 become 10 instead of 8?
YAML 1.2.2 §10.3.2 (Core tag resolution) matches plain integers as decimal [-+]? [0-9]+, octal 0o [0-7]+, and hex 0x [0-9a-fA-F]+. A leading zero is still decimal. js-yaml 5 load with CORE_SCHEMA turns value: 010 into {"value":10} and value: 0777 into {"value":777}. Octal needs the 0o prefix: value: 0o10 becomes {"value":8}. YAML 1.1 !!int (yaml.org/type/int.html) treated a leading 0 as octal (010 → 8, 0777 → 511), allowed 0b binary and _ separators, and parsed sexagesimal 1:30:00 as 5400. Core keeps 1:30:00 and 0b10 as strings. Quoted "010" stays a string so padded IDs survive. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does YAML 1_000 stay a string instead of 1000?
YAML 1.2.2 §10.3.2 (Core tag resolution) matches plain integers as decimal [-+]? [0-9]+, octal 0o [0-7]+, and hex 0x [0-9a-fA-F]+. There is no underscore. YAML 1.2.0 (2009-07-21) said underlines _ cannot be used within numerical values. js-yaml 5 load with CORE_SCHEMA turns value: 1_000 into {"value":"1_000"} and value: 1_000.5 into {"value":"1_000.5"}. Write value: 1000 for {"value":1000}. YAML 1.1 !!int (yaml.org/type/int.html) ignored _ (+685_230 → 685230). Quoted "1_000" stays a string. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does YAML 9007199254740993 become 9007199254740992?
YAML 1.2.2 §10.2.1.3 (Integer) represents arbitrary-sized mathematical integers and says a processor should bind them to a native integer type if possible. An overflow may be rejected, truncated, or otherwise round-tripped; 32-bit integers should be safe. js-yaml 5 load with CORE_SCHEMA uses parseInt, which returns a JavaScript Number (IEEE-754 binary64; ECMA-262). Exact integers end at Number.MAX_SAFE_INTEGER, 9007199254740991 (2^53 − 1). value: 9007199254740993 becomes {"value":9007199254740992}. value: !!int 9007199254740993 and hex 0x20000000000001 do the same. JSON.stringify then writes that even value. RFC 8259 §6 expects JSON number interoperability in that binary64 range. Quoted "9007199254740993" stays the exact string. This is the host Number, not a YAML 1.1 vs 1.2 type change. This page does not parse integers as BigInt. Nothing is uploaded.
Why does an empty YAML value become JSON null instead of an empty string?
YAML 1.2.2 §10.3.2 (Core tag resolution) resolves null | Null | NULL | ~ and an empty scalar (/* Empty */) as tag:yaml.org,2002:null. Spec §7.2 says omitted node content is commonly resolved as null. js-yaml 5 load with CORE_SCHEMA turns value: ~, value: null, and value: (nothing after the colon, or only a # comment) into {"value":null}. Write value: "" for {"value":""}. Quoted "null" and "~" stay strings. none and nil stay strings. An empty input stream is different: load throws “expected a document, but the input is empty”. YAML 1.1 !!null (yaml.org/type/null.html) used the same ~ / null / empty forms. .inf becoming JSON null is JSON.stringify of Infinity, not this rule. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does YAML 2026-08-20 stay a string instead of a date?
YAML 1.2.2 §10.3.2 (Core tag resolution) matches plain scalars as null, bool, int, or float; anything else is tag:yaml.org,2002:str. There is no timestamp regex. js-yaml 5 load with CORE_SCHEMA turns date: 2026-08-20 into {"date":"2026-08-20"} and date: 2001-12-15T02:59:43.1Z into {"date":"2001-12-15T02:59:43.1Z"}. YAML 1.1 !!timestamp (yaml.org/type/timestamp.html) resolved a date-only value as 00:00:00Z, so JSON.stringify of that Date would write "2026-08-20T00:00:00.000Z". An explicit !!timestamp tag throws “unknown scalar tag !<tag:yaml.org,2002:timestamp>”. Quoted "2026-08-20" stays a string. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does YAML .5 become 0.5 instead of failing like JSON?
YAML 1.2.2 §10.3.2 (Core tag resolution) matches plain floats as [-+]? ( \. [0-9]+ | [0-9]+ ( \. [0-9]* )? ) ( [eE] [-+]? [0-9]+ )?. A leading or trailing decimal point is allowed. js-yaml 5 load with CORE_SCHEMA turns value: .5 into {"value":0.5} and value: 1. into {"value":1}. The spec example lists 0., .5, +12e03, and -2E+05. value: 1e2 becomes {"value":100}. RFC 8259 §6 / ECMA-404 require an integer part and at least one digit after the point, so JSON.parse(".5") and JSON.parse("1.") throw. Write 0.5 or 1.0 for JSON-legal source. Quoted ".5" and "1." stay strings. A lone . and incomplete 1e stay strings. YAML 1.1 !!float (yaml.org/type/float.html) also allowed .5 / 1. but required a decimal point, ignored _ (685_230.15), and parsed sexagesimal 190:20:30.15. Core keeps 685_230.15 and 190:20:30.15 as strings. .inf becoming JSON null is JSON.stringify of Infinity, not this rule. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does YAML True become true instead of failing like JSON?
YAML 1.2.2 §10.3.2 (Core tag resolution) matches plain booleans as true | True | TRUE | false | False | FALSE. Those six spellings are tag:yaml.org,2002:bool. js-yaml 5 load with CORE_SCHEMA turns enabled: True into {"enabled":true} and enabled: FALSE into {"enabled":false}. RFC 8259 §3 / ECMA-404 allow only lowercase true and false, so JSON.parse("True") and JSON.parse("FALSE") throw. Write true or false in JSON. Quoted "True" and "FALSE" stay strings. Mixed-case TruE and fAlse stay strings. yes, NO, and on stay strings — the YAML 1.1 !!bool list that caused the Norway problem. YAML 1.1 !!bool (yaml.org/type/bool.html) also accepted those six plus yes/no/on/off/y/n in a fixed list of capitalizations. This is not a Python-literal parser. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does a YAML | block include a trailing newline in JSON?
YAML 1.2.2 §8.1.2 (Literal Style) denotes a block scalar with |. Line breaks inside the block stay line breaks. §8.1.1.2 (Block Chomping Indicator) defaults to clip: the final line break is kept and trailing empty lines are dropped. js-yaml 5 load with CORE_SCHEMA turns note: | with the next indented lines hello and world into {"note":"hello\nworld\n"}. note: |- is strip and becomes {"note":"hello\nworld"}. note: |+ is keep; it matches clip unless extra blank lines follow, which then stay (spec example 8.5). §8.1.3 (Folded Style) > folds consecutive non-empty lines to spaces: note: > with those same lines becomes {"note":"hello world\n"}. note: >- becomes {"note":"hello world"}. Quoted "hello\nworld" is already that string without a block header. A | block whose content is True stays the string "True\n", not a boolean — Core bool matching is for plain scalars (§10.3.2). dump may rewrite > as | or a plain scalar; quote style is not preserved. This is presentation, not a YAML 1.1 vs 1.2 type change. Nothing is uploaded.
Why does YAML 1: become JSON "1" instead of a numeric key?
YAML 1.2.2 §3.2.1.1 (Mapping) says keys may be arbitrary nodes. RFC 8259 §4 / ECMA-404 require every JSON object member name to be a string. There is no numeric-key production. js-yaml 5 load with CORE_SCHEMA builds a JavaScript object, so own keys are already strings, then JSON.stringify writes those names. 1: one becomes {"1":"one"}. true: yes becomes {"true":"yes"} — the value yes stays a string. Quoted "1": one is already that string name. 010: padded becomes {"10":"padded"} because the key is the Core integer 10 (YAML 1.2.2 §10.3.2), then ToString. ~: missing becomes {"null":"missing"}. A sequence or mapping key throws “object-based map does not support complex keys”. 1: and "1": in the same mapping throw as a duplicate key. JSON.parse('{1:"one"}') throws. This is not a YAML 1.1 vs 1.2 type change. Nothing is uploaded.
Why does YAML <<: *base become a JSON "<<" key instead of merging?
YAML 1.2.2 §3.2.2.2 / §6.9.2 / §7.1 keep anchors (&) and aliases (*). An alias composes to the anchored node. js-yaml 5 load with CORE_SCHEMA expands that node, then JSON.stringify writes two copies because JSON has no aliases. item: &id with name: Docify and copy: *id becomes {"item":{"name":"Docify"},"copy":{"name":"Docify"}}. The YAML 1.1 merge key << (yaml.org/type/merge.html) inserted keys from one or more mappings. YAML 1.2.0 (2009-07-21) removed the merge << and value = special keys. CORE_SCHEMA does not enable !!merge, so << is an ordinary string name. base: &base with host: localhost and port: 80, then app: / <<: *base / name: docify, becomes {"base":{"host":"localhost","port":80},"app":{"<<":{"host":"localhost","port":80},"name":"docify"}} — the alias expanded into the << value; host and port were not inserted beside name. <<: [*a, *b] becomes a JSON array under "<<". Quoted "<<": extra is already that string name. =: label becomes {"=":"label"}. An explicit !!merge tag throws “unknown scalar tag !<tag:yaml.org,2002:merge>”. dump with noRefs inlines copies and does not rewrite <<. This is not Kubernetes merge. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does YAML !!str 010 stay a string instead of 10?
YAML 1.2.2 §6.8.2.1 says !! is the secondary tag handle. The default prefix is tag:yaml.org,2002:, so !!str is tag:yaml.org,2002:str. §6.9.1 says an explicit tag names the type. Core §10.3.1 uses the same tags as the JSON schema: str, seq, map, null, bool, int, and float. An explicit tag skips the plain-scalar regex in §10.3.2. js-yaml 5 load with CORE_SCHEMA turns value: !!str 010 into {"value":"010"}. value: !!int 010 is still {"value":10} — Core decimal, not YAML 1.1 octal. value: !!str true is {"value":"true"}. value: !!bool true is {"value":true}. value: !!bool yes throws “cannot resolve a node with !<tag:yaml.org,2002:bool> explicit tag” because Core bool is only those six spellings. value: ! 010 (non-specific !) also becomes {"value":"010"} — §10.3.2 resolves ! to str, seq, or map by kind. Quoted "010" is already that string without a tag. !!binary, !!timestamp, !!merge, !!set, and !!omap throw “unknown scalar tag” — YAML 1.2 dropped those 1.1 types. This page does not use a YAML 1.1 schema. Nothing is uploaded.
Why does JSON "010" become YAML '010' instead of 010?
JSON → YAML calls JSON.parse, then js-yaml 5 dump with CORE_SCHEMA. dump’s default quoteStyle is single; this page does not set forceQuotes. YAML 1.2.2 §10.3.2 applies Core tag resolution to plain scalars. An unquoted 010 would load as the integer 10. §7.3.2 (Single-Quoted Style) writes a string that skips that implicit typing. dump therefore quotes a JSON string when a plain scalar would resolve as a Core int, bool, null, or float. {"value":"010"} becomes value: '010'. {"value":"true"} becomes value: 'true'. {"value":"null"} becomes value: 'null'. {"value":"yes"} stays value: yes — Core keeps yes as a string, so dump does not quote it. {"value":"2026-08-20"} stays unquoted for the same reason. {"1":"one"} becomes '1': one so the key is not the integer 1. A later YAML → JSON load keeps those quoted strings. Unquoted value: 010 still becomes {"value":10}. This is presentation, not a YAML 1.1 vs 1.2 type change. Nothing is uploaded.
Does a round trip keep comments, anchors, or key style?
No. Comments never survive load. dump writes CORE_SCHEMA YAML with 2-space indent, unlimited line width, and noRefs so duplicate objects are inlined rather than aliased. Quote style and original key order are not a formatter guarantee. This is not a YAML pretty-printer that preserves source text.

Related