{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Schema {{ resultsReady ? schemaLabelValue : '—' }} Sequence {{ resultsReady ? sequenceLabel : '—' }} Documents {{ resultsReady ? documentPairLabel : '—' }}
Paste the current or expected document. Source text stays in this browser tab and is never added to the URL.
Paste the revised document to compare against the baseline.
Comparison updates locally after every source or rule change.
Core follows YAML 1.2 scalar rules. Compatibility also resolves legacy merge keys and timestamps.
Key matching preserves identity across reordering; incompatible sequences fall back to position with a review note.
Every item needs one unique scalar value; otherwise that sequence is compared by position.
Ignore is neutral because YAML mappings are unordered in the representation model.
Enter one exact path per line. End a path with .* to ignore that branch. Empty is neutral.
Review summary
{{ row.label }}{{ row.value }}
Parser and policy notes
  • {{ notice }}
Chart unavailable.The same counts remain available in the review summary and change ledger.
ChangePathBaselineCandidateReview noteCopy
{{ statusLabel(row.kind) }}{{ row.path }}{{ row.before || '—' }}{{ row.after || '—' }}{{ row.note || '—' }}
No structural differences.The selected parser and comparison rules consider these YAML sources equivalent.
JSON Diff Comparator Compare JSON as parsed structures with configurable array matching and ignored paths, then review exact changes through path and patch evidence.
XML Diff Comparator Compare XML as parsed structure with keyed or positional node matching, namespace and whitespace policies, and exact path-level change evidence.
Text Diff Comparator Compare original and revised text locally through unified hunks and line alignment, with audited ignore rules and clear change counts.
YAML Validator Validate YAML locally with selectable scalar schemas, strict duplicate-key checks, and bounded path evidence for single or multi-document input.

Configuration review is not always a text-review problem. YAML allows the same data to be written with different indentation, quoting, scalar styles, anchors, and flow or block notation. A line diff can make harmless formatting changes look large, while a structural comparison focuses on the parsed mappings, sequences, scalar values, and scalar types that an application is more likely to consume.

Parsing also makes small-looking edits more consequential. Under one schema, an unquoted value may become a number, boolean, timestamp, or null. Under another, the same characters may stay a string. A sequence can represent an ordered command list, a set-like collection, or a list of named records. No single matching policy is correct for all three.

Difference Structural meaning Review consequence
Indentation or quote style Usually presentation only when parsing yields the same nodes. A structural report normally omits it.
Mapping key order Mappings are unordered in the YAML representation model. Order can be ignored or reported as a serialization change.
Sequence order Sequences are ordered, but some applications treat items as named records or set-like values. Choose position, unique-key, or scalar-multiset matching deliberately.
Scalar type 3 and "3" can represent a number and a string. A type change should be reviewed even when the displayed characters look similar.

A structural match does not prove that two configuration files behave the same. Applications can impose their own defaults, validation, merge rules, key-order conventions, or environment-specific interpretation after YAML is loaded. Comments and formatting may also carry human review context even though they are not part of the parsed data.

The safest review uses the schema and sequence policy of the system that will consume the document. If those rules are unknown, compare conservatively, keep ignored paths empty, and confirm important changes against the application's own validator or dry run.

How to Use This Tool:

Match the parser and sequence policy to the destination system before deciding which path-level changes matter.

  1. Paste the current or expected document into Baseline YAML and the revised document into Candidate YAML. Both texts stay in the current browser tab and are not placed in the URL.
  2. Choose YAML 1.2 core for common modern scalar rules, YAML 1.1 compatibility when legacy timestamps and merge keys must resolve, or Failsafe strings when mappings, sequences, and strings are the intended model.
  3. Set Sequence matching. Use a unique scalar key such as name for lists of records, position for ordered commands, or scalar multiset for order-insensitive lists of scalar values.
  4. Leave mapping order ignored unless serialization order itself belongs in the review. Add exact ignored paths or a branch ending in .* only for values known to be volatile and non-material.
  5. Read Review summary for notices and counts, then inspect Change ledger for the parsed path, before value, after value, and rule note behind each row.

Interpreting Results:

Change count adds changed, added, removed, and moved rows. Ignored rows are excluded from that total but remain visible so a reviewer can see that the underlying branches differed. A zero-change result therefore means no material parsed-data difference under the selected schema, sequence policy, mapping-order rule, and ignored paths.

Notices explain comparison fallbacks. Unique-key matching falls back to position if every item is not a mapping with one unique scalar value for the chosen key. Scalar-multiset matching falls back to position when a sequence contains a mapping or nested sequence. A fallback can turn a reorder into several apparent value changes, so review the notice before reading the ledger.

Comments, anchor names, indentation, quoting, scalar style, and other presentation details are not compared. Use a text diff alongside this result when those details are part of documentation, policy, or deployment review.

Technical Details:

YAML loading converts each document into a canonical tree of mappings, sequences, and typed scalars. String, number, boolean, null, timestamp, and binary values retain distinct scalar types. Mapping entries keep their written order long enough to report an optional reorder, but structural equality sorts mapping keys because key order is not part of the YAML representation model.

Transformation Core:

Stage Transformation Material effect
Load Parse every YAML document with the selected schema. Schema resolution decides scalar types and legacy merge behavior.
Canonicalize Represent loaded values as mapping, sequence, or typed scalar nodes. Presentation choices such as comments, quotes, and indentation disappear.
Address Assign paths beginning at $doc[0], with dot notation for simple keys and bracket notation for other keys. Every reported change and ignored rule has an auditable location.
Match Compare mapping keys, sequence items under the chosen policy, and scalar type plus value. Additions, removals, changes, moves, type changes, and ignored differences become ledger rows.

Rule Core:

Policy Ordered decision rule Failure or fallback
Unique key Every item must be a mapping and contain one unique, non-null scalar under the selected key. Matching identities are compared at a path such as containers[name="api"]; position changes are reported as moves. Any missing, repeated, null, or non-scalar identity makes that sequence fall back to position.
Position Compare item 0 with item 0, item 1 with item 1, and so on. An early insertion can shift every later pairing.
Scalar multiset Count canonical scalar values and report only count differences, regardless of order. Mappings and nested sequences force a position fallback.
Ignored path An exact path ignores that node; a suffix of .* ignores the named branch and every descendant. The differing branch remains as an ignored row rather than a material change.

YAML 1.2 core is the default. YAML 1.1 compatibility additionally resolves legacy types such as timestamps and the << merge key. Failsafe mode keeps scalar values as strings. Aliases are resolved to their referenced values before comparison; self-referential aliases are rejected because they cannot be represented as a bounded tree.

The comparison allows up to 120,000 characters, 20 YAML documents, 60 nesting levels, 8,000 parsed nodes, 200 aliases, and 1,000 merge keys per side. Up to 30 ignored paths and 500 ledger rows are retained. A row-limit notice means later differences were not enumerated.

Parser errors include the side and, when available, line and column. A parse failure stops structural comparison because there is no reliable typed tree to compare. Fix syntax first rather than interpreting a partial result.

Worked Examples:

Container list matched by name

A deployment changes the api image, reorders environment variables, and adds a worker container. Matching sequences by the unique key name keeps the existing api record paired even if its position changes. The image edit appears under that named path, while the worker appears as an added record.

Volatile build field ignored

Two manifests differ only at $doc[0].metadata.build. Adding that exact path produces an ignored row and reduces the material total to zero. The result supports a review only if build identity truly has no operational meaning for the destination system.

References: