免费YAML转JSON转换器

即时将YAML转换为JSON。处理所有YAML语法，包括列表、映射和锚点。完全在您的浏览器中运行。

您的数据从不离开设备
将YAML文件拖到此处 或点击浏览 （最大5 MB）

什么是YAML？

YAML（YAML Ain't Markup Language）是一种人类友好的数据序列化格式，常用于配置文件。它使用缩进和简单语法表示列表、字典和标量值等数据结构。

为什么要将YAML转换为JSON？

常见问题

支持哪些YAML功能？

该转换器支持所有标准YAML功能，包括映射、列表、字符串、数字、布尔值、空值、多行字符串、锚点和别名。

复杂的YAML结构会正确转换吗？

是的。该转换器处理嵌套结构、对象列表、注释（会被剔除）以及所有YAML语法。如果存在语法错误，您将获得清晰的错误信息。

YAML注释会保留吗？

不会。注释不是数据结构的一部分，因此不会包含在JSON输出中。

A short history of YAML, a 2001 mailing-list spin-off

YAML's prehistory begins on the sml-dev mailing list, a 2000s offshoot of xml-dev that gathered people who thought XML was overkill for human-edited data. Two parallel tracks converged: Ingy döt Net's Perl module Data::Denter, written as a serialization format for the Inline Perl module, and joint work by Oren Ben-Kiki and Clark Evans aimed at simplifying XML. On 11 May 2001, Clark Evans posted "YAML Draft 0.1" to sml-dev, and the format was first publicized in an xmlhack article the next day.

The initial expansion of the acronym was tongue-in-cheek: Yet Another Markup Language, a jab at the proliferation of markup formats in 2001. Between December 2001 and April 2002 the authors retrofitted the recursive backronym YAML Ain't Markup Language: partly to underline that YAML is a data-serialization format rather than a document-markup format like XML or HTML, and partly because the joke had aged. The recursive expansion is still the official tagline on yaml.org today.

Specification timeline

The 1.2.2 spec is explicit that "there are no normative changes from the YAML specification v1.2"; the work consisted of converting the source from DocBook to Markdown, regenerating diagrams from plain-text LaTeX, and opening the development process so external contributors could file pull requests against the spec itself. No language has shipped since 2009: every parser-conformance bug since then is either a 1.1 holdover or a deviation from a spec that has now stood for over fifteen years. The official MIME type application/yaml was finalised in 2024; the file extensions .yaml and .yml have both been recognised since around 2006, with .yaml the recommended one.

The JSON relationship, "almost a superset"

The YAML 1.2.2 spec puts it carefully: "By sheer coincidence, JSON was almost a complete subset of YAML." JSON appeared between YAML 1.0 (2004) and YAML 1.1 (2005); the YAML authors only discovered the overlap retroactively. The 1.2 revision's explicit goal, in its own words, was "making YAML a strict superset of JSON", and this is almost true for JSON-formatted YAML 1.2 documents but is not true for YAML 1.1.

In practical terms: every JSON document is valid YAML 1.2, the flow-style mapping {"a": 1, "b": [true, null]} parses identically in both. Most JSON documents are not valid YAML 1.1 because of the boolean and Norway gotchas: a JSON document containing the literal string "NO" would be re-emitted as false if round-tripped through a 1.1 parser using default settings. The reverse is never true: YAML can express things JSON cannot, comments (lost on conversion), anchors and aliases (resolved at conversion), tags (typically discarded), multi-document streams (only the first or all-as-array survive), and non-string keys on mappings.

The Norway Problem

YAML's most-cited gotcha. It's named after Norway because the ISO 3166-1 two-letter country code for Norway is NO, and YAML 1.1's boolean regex matches NO as the boolean false. Write country: NO in YAML 1.1 (or in any 1.2 parser still defaulting to 1.1 behaviour, which is most of them), parse it, dump it as JSON, and you get {"country": false}. The bug is silent, there's no warning, no type error, just data corruption.

The full YAML 1.1 boolean regex from the official yaml.org/type/bool.html schema is:

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

That's six lexemes (y/n, yes/no, on/off, true/false) with three case variants each, twenty-two strings that all become booleans without warning. A list of valid responses [y, n, maybe] becomes [true, false, "maybe"]; a feature flag dark_mode: on parses as dark_mode: true; a port-mode setting written OFF becomes false. YAML 1.2 fixed this at the spec level: the JSON-aligned core schema only recognises true, True, TRUE, false, False, FALSE and does not recognise y/n/yes/no/on/off at all. But this fix has not propagated to the field, PyYAML and LibYAML are still 1.1-default in all currently shipping versions. This converter uses js-yaml v4, which defaults to YAML 1.2 / JSON-compatible schema; it's one reason a browser-side converter is actually safer than running yaml.load() in PyYAML and converting from there.

Other implicit-typing landmines

Octal numbers. YAML 1.1 followed the C convention: a leading zero meant octal. So 010 parsed as the integer 8, and permissions: 0777 (a perfectly natural way to write a Unix file mode) parsed as 511. The YAML 1.2 fix was to require an explicit 0o prefix matching modern Python, 0o777 is 511, and 0777 is just 777. Parsers stuck on 1.1 defaults still get this wrong.

Sexagesimal numbers. YAML 1.1 inherited from earlier serialization formats the convention that any sequence of decimal digit groups separated by colons should be parsed as a base-60 (sexagesimal) integer or float. The advertised use case was time durations: 1:11:00 would parse as the integer 4260 (one hour, eleven minutes as seconds). This rule still bites people in practice when they write timestamps like 21:00 or version numbers like 2:3:4 and find them silently coerced to integers. Sexagesimal was silently removed in YAML 1.2, but PyYAML and other 1.1-default parsers still apply it.

Datetime auto-coercion. YAML 1.1 also auto-detects ISO 8601 timestamps and parses them as the host language's native date/time type, which is a problem if you wanted a string. Write version: 2024-01-15 and you get a Python date object, not the string "2024-01-15". The general lesson, hammered home by Ruud van Asseldonk's "YAML document from hell" essay: always quote strings that could conceivably be parsed as something else. Country codes, version numbers, file modes, timestamps, and any value drawn from a fixed vocabulary should be wrapped in single or double quotes.

Anchors, aliases, and the merge key

YAML's anchor/alias system lets you label a node with &name and reuse it later with *name. The classic example:

defaults: &defaults
  timeout: 30
  retries: 3
production:
  <<: *defaults
  host: prod.example.com

Here &defaults anchors the mapping, and <<: *defaults (the merge key (a 1.1 schema feature retained by most parsers) splices it into the production block. When this is converted to JSON, the alias is fully resolved) the JSON output contains the literal repeated content, not a reference. Anchors and aliases vanish, and any merge keys are flattened.

The famous failure mode of this system is the billion laughs attack: because anchors can be aliased multiple times and alias targets can themselves contain aliases, a small YAML file can expand to an enormous in-memory structure (10 levels × 10-fold nesting = 10¹⁰ string elements). PyYAML, LibYAML, and others had to add expansion limits to mitigate this. Browser-side converters have natural memory caps (the tab will OOM long before the host suffers), but the structural risk is real.

Multi-document streams and front matter

A YAML stream can contain more than one document. Documents are separated by a line containing exactly --- (also used as a directives-end marker at the start of the first document, which is why front matter in Jekyll, Hugo, and Eleventy is bracketed by --- lines). A line containing ... marks the end of a document without starting a new one, useful in streaming protocols.

Kubernetes uses --- to bundle multiple resource manifests in one file. JSON has no equivalent. A converter has three choices when it hits multi-document YAML: emit the first document only, emit a JSON array of documents, or emit one JSON document per --- separated by newlines (JSON Lines). Most converters default to the first or second option; js-yaml's loadAll returns an array.

Multi-line strings, folded vs literal

YAML has two block-scalar styles. The literal style (|) preserves newlines exactly. The folded style (>) replaces single line breaks with spaces and preserves blank lines as paragraph separators. Both accept chomping indicators: |- and >- strip all trailing newlines, |+ and >+ keep them all, and the unmodified | or > ("clip") preserves a single trailing newline. When converted to JSON, both styles produce ordinary string values, the folded block becomes one long string with embedded \n only at preserved blank lines; the literal block has \n at every line break.

What gets lost in conversion

Where YAML is actually used

YAML is everywhere in modern infrastructure: Kubernetes manifests (the entire object model is YAML by convention; multi-document files separated by --- are standard), Docker Compose (docker-compose.yml for services, networks, volumes), GitHub Actions (.github/workflows/*.yml: strict YAML 1.2 schema mostly observed but the parser still recognises on: as a key, a Norway-Problem near-miss GitHub explicitly works around), GitLab CI/CD, Ansible playbooks, CircleCI / Travis CI / Drone / Bitbucket Pipelines, Jekyll / Hugo / Eleventy / Gatsby / Astro front matter, OpenAPI / Swagger specs (officially "a JSON object that may be represented either in JSON or YAML"), Prometheus / Grafana / Loki / Tempo monitoring stack configuration, cloud-init (EC2/GCE/Azure VM first-boot provisioning), and AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager. For most of these, YAML-to-JSON conversion is essential whenever you're embedding configuration into JSON-only protocols, comparing files with jq, or feeding the output to a tool that expects JSON.

Why browser-side conversion is safer than server-side

PyYAML's yaml.load() with default settings could execute arbitrary Python code on any untrusted input via the !!python/object tag, which deserialises into actual Python objects with side effects, CVE-2017-18342, CVSS v3.1 score 9.8 (Critical), fixed in PyYAML 5.1 (March 2019) by deprecating the unsafe default and making safe_load() the recommended entry point. Java's SnakeYAML had its own equivalent (CVE-2022-1471, also CVSS 9.8) around the Constructor class allowing arbitrary instantiation. Rust's de-facto serde_yaml crate was deprecated in March 2024; the ecosystem is still settling on a successor (serde_yml, serde_yaml_ng, serde_norway).

Running parsing in the browser via js-yaml v4 sidesteps all of this: there's no server to compromise, js-yaml has no concept of arbitrary code execution via tags (unknown tags become plain scalars rather than constructed objects), and v4 defaults to the safer 1.2 schema. The Absolutool tool benefits from this by default.

More questions

How does the converter handle multi-document YAML files?

It loads them with js-yaml's loadAll, which returns an array of parsed documents, the JSON output is therefore a JSON array with one element per --- separated document. If you only have a single document, you'll get a JSON array with one element; wrap your input in ---/... markers if you want explicit single-document semantics.

Will my Kubernetes manifest convert correctly?

Almost always yes. Kubernetes uses YAML 1.2-compatible content for the most part, and js-yaml v4 handles all the standard primitives (strings, integers, booleans, nulls, sequences, mappings) plus anchors and aliases. The two pieces that don't survive are comments (stripped) and any anchors that get expanded to repeated content rather than references.

Why is my country code NO being read as a boolean?

It shouldn't be in this converter, js-yaml v4 defaults to YAML 1.2 / JSON-compatible schema, which doesn't recognise y/n/yes/no/on/off as booleans. If you're hitting this in a different tool (PyYAML, for instance), the fix is to wrap the value in quotes: country: "NO".

What's the file size limit?

5 MB on the upload widget, but pasted content can be larger if your browser has the memory. The bottleneck is the in-memory representation, not network, there is no server in the loop. For files larger than ~50 MB, consider a desktop YAML toolchain (yq on the command line, for instance) instead.

相关工具

JSON格式化器

即时格式化、压缩和验证JSON。

XML转JSON

使用完整的属性支持将XML转换为JSON。

Base64编码器

编码和解码Base64文本和文件。