YAML Diff Online

When a YAML diff is the right tool

YAML is the usual language of deployment and CI: Kubernetes manifests, Helm values, Docker Compose files, GitHub Actions workflows, and Ansible or other automation configs. Two of those files can look almost the same in an editor and still disagree in a single replica count, image tag, or environment variable. A YAML diff is for that moment. You put the previous version on the left, the new version on the right, and read every added, removed, or replaced line instead of scanning both files by eye.

This page compares the text you paste. It does not parse the YAML, so it will not tell you whether a document is valid, and it will not rewrite indentation for you. If you only need to tidy a single file, use the YAML Formatter, which does parse and dump. If the same data is available as JSON, JSON Diff can normalize whitespace first. If the file already lives in Git, a browser diff is still useful for a throwaway paste, but git diff is the better tool once the change belongs in a repository.

Use cases

Reviewing a Kubernetes or Helm change

A manifest update often mixes several decisions: a new namespace, a replica count, an image tag, and a fresh environment variable. Pasting the old and new documents makes each decision visible as its own marked line, so a review can ask “did we mean to change the namespace?” instead of rereading a long Deployment by eye. Load Sample on this page uses a small Deployment-style snippet if you want to see that kind of change first.

Checking Docker Compose or a CI workflow

Compose files and workflow YAML are easy to misread because most of the file did not change. A one-value edit — a port, a service image, a cron schedule — is easier to trust when it is the only green or red line on the page. Comments travel with the text, so a rewritten comment will also show up.

Comparing an export that was never committed

Cluster dumps, copied values files, and snippets from a ticket often never become a pull request. Pasting both versions here is faster than creating a throwaway Git repo, as long as you remember that the result is a text diff, not a parsed tree of resources.

How the comparison works

When you choose Compare, the two panes are compared line by line, using the same style of alignment you see in a typical unified or split diff. Identical lines stay across from each other. A line that exists only on the left is marked as removed. A line that exists only on the right is marked as added. You can switch between split and unified views, and copy the unified result if you need a record.

There is no pretty-print toggle and no schema check. Spaces, tabs, blank lines, comments, and --- document separators are all part of the text. That honesty matters: the result is easy to read, and it will not pretend that two documents are the same when only a parser would consider them equivalent.

spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: my-app:1.0.0

spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: my-app:2.0.0
          env:
            - name: NODE_ENV
              value: production

The replicas line appears as a replacement of 1 with 3. The image tag changes on its own line. The new env block appears only on the right. That is the distinction you want in a review: an edited replica count is not the same kind of change as a new environment variable.

resources:
  limits:
    memory: "128Mi"
    cpu: "250m"

resources:
    limits:
        memory: "128Mi"
        cpu: "250m"

These two resources blocks may be accepted as the same mapping by a YAML parser, but the indentation is different, so every line is marked as changed. If that is the only difference you see, format both sides the same way — the YAML Formatter can produce a consistent dump — and compare again.

What this tool does not do

It does not parse YAML 1.1 or 1.2, resolve anchors and aliases, sort keys, expand Helm templates, or talk to a cluster. Multi-document files are compared as a single block of text, not as a list of resources. Nothing is sent to a server. Very large dumps can still be pasted, but they may make the tab feel slow. If you need a formatted Compose file on its own, the Docker Compose Formatter is a better starting point than this diff page.

How to use YAML Diff

1. Paste the older or expected YAML into the original pane.
2. Paste the newer YAML into the modified pane.
3. Choose Compare. Switch between split and unified views, and copy the result if you need to keep a record.
4. Use Swap if the sides are reversed, Clear when you are finished, or Load Sample to try a small Deployment-style example first.

If you later need the same data as JSON, the JSON to YAML converter also converts in the other direction. For a text comparison of TOML instead of YAML, use TOML Diff.

Frequently asked questions

Related tools and guides

References

• YAML 1.2.2 defines indentation, mappings, sequences, and multi-document streams. This page does not implement that specification; it only compares the text you paste.
• Official tools such as kubectl diff or a schema-aware linter are a better fit when you need to know whether a manifest is valid for a cluster, not just how two files differ as text.
• If the same configuration also exists as JSON, convert it first and use a JSON-aware comparison when key order and wrapping are getting in the way.