What this checks
Paste two versions of one or more Kubernetes manifests — what's currently deployed versus what you're about to apply, staging versus production, before versus after a kubectl edit — and see exactly what changed, resource by resource, field by field. This is a structural diff, not a text diff: resources are matched by kind + namespace + name, so reordering fields, reindenting, or moving a resource earlier in the file never shows up as a false change. Within a matched pair, every field that was added, removed, or changed is listed by its path, so a spec.replicas: 2 → 3 reads as one line, not a wall of reformatted YAML.
By default, fields the cluster itself injects — status, metadata.resourceVersion, uid, generation, creationTimestamp, managedFields, and the kubectl.kubernetes.io/last-applied-configuration annotation kubectl apply writes — are stripped before comparing. Without that, diffing a kubectl get -o yaml dump against a hand-written manifest would show a wall of noise on every single resource, even ones that are otherwise identical. Uncheck the box to see everything, including that noise, if you need it.
A resource whose apiVersion changed (say, migrated off a deprecated one — see Kubernetes YAML Validator for exactly which ones are removed) shows up as one changed field on a matched resource, not as one resource removed and an unrelated one added, since matching is based on identity, not on every field being identical.
What it doesn't do
This doesn't talk to a cluster — it only compares two blocks of YAML you provide, so it can't tell you what a live object actually looks like right now (use kubectl get -o yaml to get that text first, then paste it in). It also doesn't simulate a three-way merge the way kubectl apply does internally — this shows the difference between the two documents you gave it, not a prediction of exactly how the API server will reconcile them.
FAQ
Why match resources by name instead of position in the file?
Because the order resources happen to be written in a file is never meaningful — someone could reorder a multi-document YAML file entirely and nothing about the actual cluster state would change. Matching by kind + namespace + name mirrors how Kubernetes itself identifies an object.
Should I leave "ignore server-managed fields" checked?
Yes, for almost every real comparison — those fields are set by the cluster, not by whoever wrote the manifest, and they're expected to differ between a live dump and a source-controlled file even when nothing meaningful changed. Uncheck it only if you're specifically trying to see how those fields themselves evolved.