YAML Cross-Runtime Preflight
Paste a YAML document — a GitHub Actions workflow, a Docker Compose file, a Kubernetes manifest, or plain YAML for a generic library — and see which structural features and ambiguous values would behave differently depending on which tool reads it. This tool builds directly on the YAML Semantic Difference Checker: it reuses that tool's YAML 1.1 vs 1.2 scalar-ambiguity detection wholesale (the 'Norway problem' and its relatives) and adds a broader set of structural checks that matter specifically to real YAML consumers — anchors/aliases, merge keys, tab indentation, duplicate keys and flow-style usage.
Processed locally in your browser. Your file is never uploaded.
How to use this calculator
- Paste your YAML, or upload a .yaml/.yml file — nothing leaves your browser.
- Select "Check YAML".
- Review each flagged issue: which runtimes/tools it affects and why.
- Use the suggested portable rewrite (tabs converted to spaces, ambiguous scalars quoted) where offered — some issues (anchors, merge keys, duplicate keys) are flagged only, since a safe automatic fix isn't possible without risking a structural change you didn't ask for.
Assumptions
- Scalar-ambiguity detection (rule 1) is identical to the YAML Semantic Difference Checker's own logic — the same YAML 1.1 vs YAML 1.2 Core Schema comparison, reused directly rather than re-implemented, just re-framed here for its relevance to specific runtimes (e.g. a GitHub Actions matrix value like `flag: on`).
- Structural checks (anchors/aliases, merge keys, tab indentation, duplicate keys, flow style) are pattern/indent-based checks over the same narrow block-mapping scope as the semantic checker — not a full YAML parser.
- "Affected" runtimes reflect widely-documented real constraints (e.g. Kubernetes' removal of merge-key support, kubectl's alias restrictions) — not an exhaustive audit of every version of every tool.
Methodology
The document is analyzed in two layers. First, every plain scalar is resolved under both YAML 1.1 and YAML 1.2 Core Schema rules (identical logic to the YAML Semantic Difference Checker) — any disagreement is flagged and re-explained for its relevance to specific runtimes. Second, the document is scanned for structural features known to vary across real-world YAML consumers: anchor/alias usage (warning — some tools restrict or disable these to prevent recursive-expansion resource exhaustion), merge keys (error — a YAML 1.1 extension outside the YAML 1.2 spec, unsupported by Kubernetes and many strict parsers), tab-indentation (error — forbidden by the YAML spec itself), duplicate keys within one mapping (warning — the spec leaves this unspecified, and most parsers silently keep only the last occurrence), and flow-style collections inside an otherwise block-style document (info — a low-confidence hint, not a real problem).
Worked example
A GitHub Actions matrix value that looks like a flag
Inputs: flag: on
Result: Reuses Tool 1's Norway-problem detection: YAML 1.1 reads "on" as boolean true, YAML 1.2 reads it as the string "on". In a GitHub Actions matrix or env value, this is exactly the kind of value that was probably meant to stay a string.
A Docker Compose merge key
Inputs: <<: *defaults
Result: Flagged as an error: merge keys are a YAML 1.1 extension, not part of the YAML 1.2 spec, and unsupported by Kubernetes YAML processing and several strict parsers. No automatic rewrite is offered — resolve the referenced anchor's content manually if you need a portable version.
Tab-indented Kubernetes manifest
Inputs: \tname: demo
Result: Flagged as an error (tabs are forbidden by the YAML spec, not just discouraged) with a suggested rewrite converting each leading tab to 2 spaces.
Practical guidance
- Treat merge keys and tab indentation as must-fix — they're spec-forbidden or unsupported by name in tools you're likely already using (Kubernetes, strict parsers).
- Treat anchors/aliases as worth a second look if the document will ever pass through kubectl or a security-conscious YAML loader, since some restrict alias expansion specifically to prevent YAML-bomb-style resource exhaustion.
- Re-check any value flagged by the reused scalar-ambiguity rule (rule 1) the same way you would on the YAML Semantic Difference Checker — quote it if it should stay a string.
Common mistakes
- Assuming a merge key that works fine in Docker Compose will also work in a Kubernetes manifest — Kubernetes dropped merge-key support years ago.
- Copy-pasting a block and forgetting to remove or rename the original key, producing a silent duplicate key that most parsers resolve by just keeping the last one.
- Mixing tabs and spaces in the same file after a copy-paste from a tab-indented source — some parsers tolerate it, most don't, and the visual result in an editor can look identical either way.
FAQs
Why does this tool overlap with the YAML Semantic Difference Checker?
It doesn't duplicate it — it reuses it. Rule 1 here calls that tool's own scalar-resolution logic directly rather than re-solving the same problem, then adds structural checks (anchors, merge keys, tabs, duplicate keys, flow style) that the semantic checker deliberately leaves out of scope.
Why are merge keys an error but anchors/aliases only a warning?
Merge keys are outside the YAML 1.2 spec entirely and are concretely unsupported by name in tools like Kubernetes' YAML processing — a near-certain break. Anchors/aliases are valid, widely-supported core YAML that some tools merely restrict for security reasons, which is a real but less certain risk.
Why doesn't this tool auto-fix anchors, merge keys or duplicate keys?
Each of those requires understanding what the document actually means (what an anchor's expanded content is, which duplicate occurrence was intended) rather than a mechanical text change — the tool flags them and explains the manual fix instead of guessing.