What this does
Paste one or more ----separated Kubernetes manifests and get back consistently indented YAML with top-level fields reordered into the convention every style guide (and kubectl get -o yaml itself) follows: apiVersion, kind, metadata, then spec/data/status. Nothing else about the structure changes — nested fields keep whatever order you wrote them in, and comments move with whatever line they were attached to, not left behind or dropped.
Reordering only touches the top level. A manifest with spec: written before kind: — a common result of copy-pasting between resources, or editing an existing file field-by-field — comes back with apiVersion/kind/metadata up front where they're easiest to scan, without touching how spec itself is organized internally.
What it doesn't do
This is formatting only — it doesn't check whether the manifest is actually valid. For structural correctness, removed/deprecated apiVersions, and naming rules, run it through Kubernetes YAML Validator first or after. It also doesn't strip server-generated fields (status, metadata.resourceVersion, metadata.uid, and similar) that show up when a manifest was produced by kubectl get -o yaml against a live cluster — those are left exactly as found, since removing them silently could change what you intended to keep.
FAQ
Why reorder top-level fields at all — doesn't YAML not care about order?
The Kubernetes API genuinely doesn't care what order fields appear in — this is purely for humans. A manifest is far faster to scan when apiVersion/kind/metadata.name are the first three things you see, which is also why kubectl's own YAML output is always ordered this way.
Will this ever reorder something and break my file?
No — reordering keys within a YAML mapping never changes what they mean, since a mapping is defined by its key/value pairs, not their position. The only thing that changes is reading order, never behavior.