YAML to JSON converter

What does the YAML-to-JSON converter do?

The converter reads YAML 1.2 strict and emits JSON — bidirectional, with multi-document support and profile-specific hints for the major 2026 YAML use cases: Kubernetes, Docker Compose, GitHub Actions, Helm.

Pure-client. Every input stays in your browser. No signup, no server upload, no tracking — you can verify this in the browser dev tools’ Network tab yourself.

Five properties set it apart from standard converters:

• YAML 1.2 strict with Norway lint. The parser runs in 1.2 strict mode — NO, yes, off stay strings. The Norway lint warns anyway because many downstream parsers still default to 1.1.
• Anchor and alias visualizer. Edge list with definition line and every use (*alias and << merge keys distinguished) — before the resolution happens.
• Workflow profiles. Kubernetes, Compose, GHA and Helm validators check the required fields of each target tool, without turning the converter into a strict linter.
• Comment preservation on the reverse path. JSON → YAML can optionally carry comments forward from an original YAML source, path-aligned.
• Type-fidelity table. Datetime, binary and custom tags are listed below the JSON output so type loss does not happen silently.

What is the Norway bug and how does the tool handle it?

The Norway bug is the most-quoted YAML trap: under YAML 1.1, NO parses as Boolean false because the token belongs to the 1.1 bool family (yes/no/on/off, every case variant). A naive country list like allowed: [DE, FR, NO, ES] becomes ['DE', 'FR', false, 'ES'] — Norway disappears without the parser raising an error.

YAML 1.2 removed this behaviour; only true and false are still Boolean. But many parsers in the wild still default to 1.1 because the update was a breaking change. Python’s PyYAML defaults to 1.1 through version 6, Ruby’s Psych does as well. Sites like strictyaml’s docs document the history in detail.

The lint in this converter scans the source for exactly these tokens: NO, Yes, off, octal integers with a leading 0 (0755), sexagesimal values (22:22). Found a match? It shows the line, the token and a concrete fix ("NO" quoted, 0o755 as explicit octal). The tool never blocks the conversion — it only shows where the 1.1/1.2 line runs through your code.

What are the workflow profiles for?

Generic YAML-to-JSON converters are format-translation only. They do not know that a Kubernetes manifest without apiVersion and kind is rejected by the API server, or that GitHub Actions does not resolve YAML anchors.

The profiles in this converter fill exactly that gap:

• Kubernetes — checks the three API-server-required fields apiVersion, kind, metadata.name and emits an info-level hint when a namespaced kind (Deployment, Service, …) is missing metadata.namespace. Multi-document-aware: each resource is checked separately.
• Docker Compose — checks services: is present (required), flags the in-Compose-v2 obsolete version: field as info, accepts x- extension keys and flags unknown top-level keys.
• GitHub Actions — checks on: and jobs: (required), emits an info note when name: is missing, and warns when YAML anchors are detected because Actions does not honour them.
• Helm — checks Chart.yaml convention: apiVersion: v2, name, version, type.

Every hint is non-blocking. They add context to the JSON output, they never reject it. If you need strict validation, run kubeval, kustomize, docker compose config, helm lint locally.

How does the anchor and alias visualizer work?

YAML anchors (&name) and aliases (*name) are the DRY mechanism of the language. You define a chunk of configuration once and reference it multiple times. << is the merge key: it merges the fields of the referenced map into the current map, with override capability.

The practical problem: once a file has two or three anchors, you lose track of where things are defined and which override wins. The visualizer fixes that with a compact edge list:

• Every anchor appears once with &name and its definition line.
• Below it sits the list of uses with line number and type badge (merge for <<, alias for plain *name).
• For an entry like defaults: &d used as <<: *d in two configurations, you see at a glance that d serves as a merge source twice.

The visualizer scans the source textually — fast, no full parser analysis. Limit: anchors in flow-style sequences ([a: &x 1]) spanning multiple lines are not caught, but that style is extremely rare in DevOps configurations.

How does comment preservation work?

JSON has no comments per spec. Round-tripping YAML → JSON → YAML loses every comment on the first leg — and they do not come back, because the JSON has no record of them.

The comment-preservation toggle (visible only on the JSON → YAML direction) solves that with a second input: the original YAML. With the toggle on:

1. The converter parses the original YAML into an AST with comment properties on every node.
2. It emits a fresh YAML from the JSON.
3. It walks both AST trees in parallel and copies comments by path onto the fresh YAML.

Header comments stay header, leading comments stay leading, trailing comments hang behind the right value again. Mappings match by key, sequences match by index.

Limit: if you rename keys in the JSON, shift fields, or restructure, the comment at that path falls off — the path match finds nothing. If you really need comments preserved, keep the structure recognisable.

What is intentionally not built?

• No live YAML editor. The converter parses as you type, but does not offer syntax completion or schema-aware autocomplete. Use VS Code with the YAML extension for that.
• No custom-tag extension. !Ref, !GetAtt, !Sub from CloudFormation or Ansible- specific tags parse tolerantly but are not evaluated. Use aws cloudformation validate- template for full validation.
• No Helm template rendering. Helm charts with {{ .Values.x }} placeholders need the Helm binary. We render Chart.yaml directly; values.yaml is treated as generic YAML.
• No full K8s schema validation. The K8s hints are heuristic. For full validation against the current schema, use kubeval or kustomize build | kubectl --dry-run=server apply.
• No anchor auto-refactoring. DRY suggestions (“you could extract an anchor here”) break the refined-minimalism approach of this tool.

Where do I find more details?

• YAML 1.2 spec — the official specification
• YAML on Wikipedia — history and properties
• Norway-problem explainer — why 1.2 removed implicit types
• Kubernetes object convention — apiVersion, kind, metadata
• Docker Compose reference — Compose schema
• GitHub Actions workflow syntax — workflow reference