工具代码会在浏览器中处理所选文件和输入内容，不会将其提交给 TOOLGRID 的处理接口。 TOOLGRID 只衡量工具使用情况，不记录你输入的内容。
- 不上传工具输入至 TOOLGRID
- 不登录
- 复制前先检查
Loading tool…
这个工具能做什么
In-browser JSON ↔ YAML converter built on js-yaml. Handles Kubernetes manifests, Docker Compose, ESLint configs, GitHub Actions, and more.
Pick a direction (JSON → YAML or YAML → JSON), paste your input, and the tool converts it live as you type. Both directions use the js-yaml library — the de-facto standard YAML parser/serializer for the JavaScript ecosystem, used by tools like ESLint config loading, Prettier, GitHub Actions runners, and countless others.
Configurable indent (2 or 4 spaces) on both sides. Output JSON is pretty-printed; output YAML uses block style (the readable form) rather than flow style. References (anchors) in YAML are dereferenced into the equivalent JSON value during YAML → JSON conversion since JSON has no native concept of references.
Safe mode (default ON for YAML → JSON) restricts the YAML parser to the CORE_SCHEMA — only the standard scalar types (string, number, bool, null) plus arrays and maps. Disabling safe mode allows JS-YAML-specific extensions like !!js/function, but those are non-portable and unsafe with untrusted input.
Common workflows: translate a JSON config sample from an API into Kubernetes-friendly YAML; convert a Docker Compose YAML into JSON for an automated tool that doesn't read YAML; round-trip configs to verify they don't lose data; debug YAML parsing issues by viewing the JSON equivalent. Pair with our JSON Formatter when the JSON side needs validation or pretty-printing first.
这个工具适合解决什么问题
Some Kubernetes operators emit JSON; humans usually edit YAML. Convert between them when copy-pasting examples from docs, switching between tools that prefer different formats, or generating manifests programmatically from JSON-emitting scripts.
Docker Compose YAML is human-friendly but some CI / introspection tools (especially TypeScript-typed ones) prefer JSON input. Convert your compose file once and feed both formats to different parts of your pipeline.
When a YAML config is being parsed incorrectly (wrong types, unexpected nesting, anchor expansion surprises), convert to JSON to see the exact structure your YAML parser is producing. JSON's strict typing reveals what YAML's loose typing hid.
依赖结果前需要检查什么
- Performance and maximum practical input size depend on browser memory, device speed, and the structure of the input.
- Review the generated result before replacing or publishing an original file.
如果还需要校验、转换或复用结果，可以继续打开相近的浏览器本地工具。
如何使用
01使用场景
Some Kubernetes operators emit JSON; humans usually edit YAML. Convert between them when copy-pasting examples from docs, switching between tools that prefer different formats, or generating manifests programmatically from JSON-emitting scripts.
Docker Compose YAML is human-friendly but some CI / introspection tools (especially TypeScript-typed ones) prefer JSON input. Convert your compose file once and feed both formats to different parts of your pipeline.
When a YAML config is being parsed incorrectly (wrong types, unexpected nesting, anchor expansion surprises), convert to JSON to see the exact structure your YAML parser is producing. JSON's strict typing reveals what YAML's loose typing hid.
Some configs are easier to template in JSON (or your template engine outputs JSON). Generate the JSON via your template, then convert to YAML for the final consumer.
If you suspect a config conversion is losing data, convert JSON → YAML → JSON (or vice versa) and diff against the original with our JSON Diff Checker. Differences reveal type-coercion losses (often booleans treated as strings, or vice versa).
使用技巧
- 01YAML booleans have an evil-yaml gotcha
In YAML 1.1 (which many parsers still default to), values like <code>yes</code>, <code>no</code>, <code>on</code>, <code>off</code>, <code>Y</code>, <code>N</code> are booleans. The Norway problem (country code <code>NO</code> in unquoted form becoming <code>false</code>) bit many people. YAML 1.2 fixed this but old parsers persist. If your input has such values, quote them explicitly to keep them as strings.
- 02Indentation matters in YAML, doesn't in JSON
JSON is brace-delimited so indentation is decoration. YAML uses indentation as structure — change indent and you change meaning. Convert JSON → YAML with the indent your target system expects, especially when piping into systems with strict format requirements (Helm, Ansible).
- 03Safe mode is the right default
Custom YAML tags like <code>!!js/function</code> or <code>!!js/regexp</code> allow code execution during parsing — extremely dangerous with untrusted input. Safe mode (CORE_SCHEMA) rejects these. Only disable safe mode when you control the input and have a specific reason.
- 04Anchor / alias expansion happens during YAML → JSON
YAML anchors (<code>&name</code> / <code>*name</code>) are dereferenced into copies during conversion, because JSON has no equivalent. If your YAML relies on anchor sharing (e.g., two keys both pointing to the same object), the JSON output has two independent copies. Most uses don't care, but be aware if you're processing the JSON further.
常见问题
02What YAML version is supported?
The js-yaml library supports YAML 1.2 with the CORE_SCHEMA by default in safe mode. Most modern YAML you'll encounter (Kubernetes manifests, Compose files, GitHub Actions, ESLint configs) conforms to YAML 1.2 and parses cleanly.
Does the conversion run entirely in my browser?
js-yaml is a pure-JavaScript library shipped as part of the page. Conversion runs in your browser, and tool code does not submit entered YAML or JSON to a TOOLGRID processing endpoint. Review browser extensions and device security before handling sensitive configuration.
Why does my YAML fail to parse?
Most common causes: (1) inconsistent indentation (tabs vs spaces, or different space widths), (2) missing colons after keys, (3) unquoted strings that the parser interprets as booleans (yes/no/on/off — the Norway problem), (4) custom !!type tags that safe mode rejects. The error message points at the line; fix incrementally.
Does YAML support things JSON doesn't?
Yes. YAML has comments (#), multi-line strings (>, |), anchors and aliases (&, *), and explicit tags (!!). JSON has none of these. When converting YAML → JSON, comments are dropped, multi-line strings are collapsed to single strings (preserving line breaks via \n), anchors are dereferenced, and custom tags either parse to their underlying type or fail in safe mode.
What happens to YAML comments during conversion?
They're dropped. JSON has no native comment syntax (despite many parsers permissively allowing them). If you need to preserve comments through a round-trip, use a comment-aware library like js-yaml's full schema mode with manual handling — but most workflows accept comment loss as a known trade-off.
Can I convert a YAML file with multiple documents?
js-yaml supports multi-document YAML (separated by <code>---</code>), but the tool currently loads only the first document. For multi-document files, split them on <code>---</code> first and convert each separately.
Is the converter lossless for round-trips?
JSON → YAML → JSON is lossless for any valid JSON input. YAML → JSON → YAML may not be lossless because YAML has features JSON lacks: comments, anchors/aliases, multi-line string styles, and explicit tags. The semantics are preserved; the surface form may not be.