Paste or drop a YAML manifest and find out whether it is valid, and if not, the exact line and column with the reason in plain language. Then the Kubernetes-specific checks: deprecated APIs, invalid names, and the values YAML quietly changes on you.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Validate manifest. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A working Deployment and everything a hardened cluster will reject about it
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
template:
spec:
containers:
- name: app
image: api:latestA manifest that applies to whichever namespace happens to be current
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The manifest applies to whichever namespace kubectl currently points at, which is how something lands in the wrong one.
Instead:Set metadata.namespace, or apply with -n explicitly.
It defaults to true, so a process can gain privileges through setuid binaries. Restricted Pod Security admission rejects it.
Instead:Set securityContext.allowPrivilegeEscalation: false.
The image is not pinned, so a rollout can pull something different and a rollback cannot reproduce the old one.
Instead:Pin a tag, and a digest where you can.
Validity first, because a manifest that will not parse is the urgent problem and every parser reports it badly. Then the things that parse fine and still go wrong.
The parse error in plain language, with an excerpt and a caret under the exact character. Bad indentation, tabs, unclosed quotes, duplicate keys, a stray colon in an unquoted value: each gets an explanation of the likely cause rather than the parser's own wording.
Tabs in indentation (which YAML forbids outright), indentation that is not a multiple of the file's own step, indentation that jumps a level, trailing whitespace, Windows line endings, a byte order mark, a missing final newline, and control characters that arrive invisibly by pasting from a terminal.
Unquoted NO, yes, on and off become booleans in the YAML 1.1 parsers Kubernetes uses. 0644 becomes the number 420. A chart_version of 1.10 becomes 1.1 and the zero is gone. These parse fine and go wrong later, which is the worst kind.
Missing apiVersion or kind, objects with no name, names that are not valid DNS subdomains (uppercase and underscores are the usual culprits), and pod templates with no containers or no image.
extensions/v1beta1, apps/v1beta1, policy/v1beta1, batch/v1beta1, autoscaling/v2beta2 and the rest, each with the version that removed it and what to migrate to. These are the manifests that break during a cluster upgrade rather than at review time.
Privileged containers, hostPath mounts, containers that can run as root, secrets pasted as literal env vars, wildcard RBAC, and the missing requests and limits that make a cluster bill larger than it needs to be. Filter these out by severity if you only came for the syntax.
This checks the file you paste. A running cluster contains rather more than that: workloads deployed by a Helm chart nobody maintains, a namespace created for a proof of concept two years ago, node pools sized for a traffic peak that never came back.
It also cannot see what the file does not say. Whether a NetworkPolicy exists, whether the ServiceAccount this pod uses is bound to something powerful, whether the image tag you pinned has a critical CVE, and whether the nodes it lands on are half empty. Those answers live in the cluster.
Our scanner connects with a read-only ServiceAccount and answers them, alongside the cost of every node, volume and load balancer keeping the cluster alive.
Every Kubernetes object, whatever it is, has the same four top-level keys. Once that shape is clear, the difference between a Deployment and a CronJob is only what goes inside spec, and most manifest errors turn out to be one of a small set of structural mistakes rather than anything to do with the workload itself.
apiVersion says which API group and version this object belongs to. kind is the type. metadata carries the name, namespace and labels. spec is the desired state, and it is the only part whose shape depends on the kind. Anything the cluster reports back appears under status, which you never write yourself.
apiVersion: apps/v1 which API, and which version of it
kind: Deployment what type of object
metadata: name, namespace, labels, annotations
name: api
spec: desired state: shape depends on kind
replicas: 2API versions graduate from alpha to beta to stable, and the older names are removed after a deprecation period. A manifest written against extensions/v1beta1 stopped applying at Kubernetes 1.16, and networking.k8s.io/v1beta1 Ingresses stopped at 1.22. The manifest is still valid YAML and the cluster simply refuses it, which is why a file that worked for years fails immediately after an upgrade.
apps/v1 Deployment, StatefulSet, DaemonSet
batch/v1 Job, CronJob
networking.k8s.io/v1 Ingress, NetworkPolicy
v1 Pod, Service, ConfigMap, Secret: core groupA Deployment does not own its Pods directly. It creates a ReplicaSet, which finds Pods by matching labels, and the link between them is spec.selector.matchLabels matching spec.template.metadata.labels exactly. Get them out of step and the Deployment either creates Pods it does not recognise and keeps making more, or is rejected outright, and on an existing Deployment the selector is immutable, so the fix is to delete and recreate it.
spec:
selector:
matchLabels:
app: api <-- these two must match exactly
template:
metadata:
labels:
app: api <-- or the Deployment owns nothingThree dashes on their own line separate documents, which is how a Deployment, a Service and an Ingress travel together in one file. The separator is YAML, not Kubernetes, so each document is parsed independently: a syntax error in the third one does not stop the first two from being read, and a stray separator produces an empty document that some tools reject and others silently skip.