Kubernetes Manifest Diff
Compare two sets of manifests by what they mean rather than by their text. Key order, reordered containers and everything the cluster wrote itself are ignored, so what is left is the change you actually made.
Nothing is uploaded: the comparison runs in this tab.
Differences
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Diffing files rather than applied state
A file diff misses defaulted fields, mutating admission changes and anything a controller added. The cluster's copy differs from what you wrote.
Instead:kubectl diff compares against the live object, which is the comparison that matters.
Treating a field the server added as a change
creationTimestamp, resourceVersion and status appear on the live object and never in your file.
Instead:Ignore the server-managed fields, which is what this page does.
Assuming an empty diff means no effect
Applying can still trigger a rollout if a template annotation changed, and can fail on an immutable field even when the diff looks small.
Instead:Check what is immutable before applying.
What it ignores
The value of a semantic diff is almost entirely in what it declines to tell you.
Key order is not a change
YAML mappings have no meaningful order, so any tool that round-trips a manifest reshuffles it and a text diff lights up end to end. This compares objects rather than lines: two files with every key in a different order are reported as identical, because they are.
Containers matched by name
Lists of named things: containers, ports, environment variables, volumes: are matched on their name rather than their position. Moving a sidecar above the app container is not a change to either of them, and a text diff insists it is a change to both.
Cluster-written fields ignored
status, resourceVersion, uid, generation and managedFields are written by the cluster, never by you, so comparing them produces a difference on every object every time. Paste kubectl get -o yaml output straight in and none of it appears.
Defaults counted, not listed
The API server fills in imagePullPolicy, terminationMessagePath, dnsPolicy and a long tail of others. Comparing a file against a live object shows every one as added, which is true and useless, so they are counted in a single line rather than drowning the real change.
Why a text diff of two manifests is nearly useless
Comparing Kubernetes manifests looks like a solved problem: they are text files, and diff exists. In practice a line-by-line comparison of two manifests that mean the same thing routinely shows dozens of differences, and one that hides a real change shows it among a hundred lines of noise.
YAML mappings have no order
A mapping is a set of key-value pairs and the specification attaches no meaning to their sequence. Every library that parses and re-emits YAML picks its own order: alphabetical, insertion, or whatever the internal map produced. So a manifest that has been through Helm, Kustomize, or kubectl comes back semantically identical and textually unrecognisable.
these two are the same object
metadata: spec:
name: api replicas: 2
spec: metadata:
replicas: 2 name: api
diff reports every line changedLists are ordered, but not all of them meaningfully
Sequences do have order in YAML, and sometimes it matters: init containers run in sequence, and command arguments obviously do. For containers, ports, env vars and volumes it does not: Kubernetes matches those by name. A diff that compares them by index reports a reordering as every element having changed into a different element.
Half of a live object was never written by you
Pull an object back with kubectl and it carries status, the resourceVersion, the uid, the generation, managedFields recording every field-manager that touched it, and the last-applied-configuration annotation containing a full copy of the previous manifest. None of that is yours to compare. It is also most of the bytes.
metadata:
creationTimestamp: "2026-01-14T09:12:03Z" cluster
generation: 7 cluster
resourceVersion: "88412119" cluster
uid: 0f3a... cluster
managedFields: [ ... 200 lines ... ] cluster
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{ ...a whole copy of the old manifest... }And the API server adds fields you omitted
Anything you leave out gets a default written into the stored object: imagePullPolicy, terminationMessagePath, dnsPolicy, restartPolicy, schedulerName, an empty securityContext, a clusterIP on every Service. Comparing your file against the cluster shows all of them as additions. They are real, they are not your change, and they are why a file-versus-cluster diff is usually abandoned rather than read.
What kubectl diff does, and where it stops
kubectl diff --server-side is the right tool when you have cluster access: it asks the API server what would change, so it accounts for defaulting and admission webhooks in a way nothing offline can. It needs credentials and a reachable cluster, which is exactly what you do not have when reviewing a pull request, comparing two environments from their manifests, or working out what a Helm upgrade would do before running it. That gap is what this page is for.