Kubernetes YAML Validator
Paste a Kubernetes manifest (or several, separated by ---) and check it against the real Kubernetes schema before you kubectl apply it.
Drop a .yaml/.yml file here, or paste manifest text above.
Multiple manifests separated by "---" are validated as separate documents.
Advanced options
Parsing and validation run in your browser. Only schema files are fetched from a public CDN: the resource schema and, for custom resources, the CRD catalog entry — requested by group/kind/version only, your manifest is never sent.
Paste a Kubernetes manifest above (or load the sample) and the validation results will appear here.
Catching Kubernetes manifest mistakes before kubectl does
A rejected `kubectl apply` is usually the first time a mistake in a Kubernetes manifest becomes visible — and by then you're often mid-deploy, staring at an error message that quotes a JSON Schema validation path (`spec.template.spec.containers[0].image: Required value`) that doesn't obviously map back to the YAML file you were just editing. Catching the same class of error earlier, with the exact line highlighted, turns that into a five-second fix instead of a context switch.
YAML's own syntax has sharp edges that don't show up in most other config formats: indentation is significant and inconsistent tabs/spaces will silently produce a different (wrong) structure rather than an error in some cases, `---` document separators are easy to lose track of in a long multi-resource file, and a stray extra level of nesting reads as valid YAML while meaning something completely different to Kubernetes. This tool parses with the same library approach that keeps full source position information through parsing, so a syntax problem is reported against the real line it occurs on, not just "somewhere in this 200-line file."
Deprecated apiVersions are a slower-motion trap: `extensions/v1beta1` Deployments, `apps/v1beta1`/`apps/v1beta2` StatefulSets and DaemonSets, and `networking.k8s.io/v1beta1` Ingresses all still parse as perfectly valid YAML and even worked on older clusters — until the cluster gets upgraded past the version where Kubernetes finally removes the old API group entirely, at which point every manifest using it starts failing to apply with no warning beforehand. Catching these while editing (with the exact replacement apiVersion suggested) avoids finding out during a cluster upgrade instead.
Schema validation against the real Kubernetes OpenAPI spec catches the rest: a `replicas` field that ended up as a quoted string instead of a number, a `containerPort` outside the valid range, a required field like `spec.selector` on a Deployment that got deleted while copy-pasting between manifests. None of these are YAML syntax errors — the file parses fine — which is exactly why a dedicated schema pass catches what a quick visual read of the file usually doesn't.
Frequently asked questions
Does this replace `kubectl apply --dry-run` or `kubeconform`?
No. `kubectl apply --dry-run=server` is the only check that runs against your actual cluster's API server (including any CRDs and admission webhooks it has installed), and `kubeconform`/`kubeval` are mature CLI tools built for CI pipelines. This validates the same class of things — YAML syntax, schema shape, deprecated apiVersions — from a browser tab, before you have `kubectl` configured against anything, or while reviewing a manifest someone else sent you.
Where do the schemas come from?
From `yannh/kubernetes-json-schema`, a community-maintained, automatically-updated mirror of Kubernetes's own OpenAPI-derived JSON Schemas, fetched on demand from a public CDN for the Kubernetes version you pick. Nothing about your manifest is sent anywhere — only the (versioned, public) schema file itself is downloaded, the same file for every user validating that kind/version.
Why only 10 resource kinds?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob, and PersistentVolumeClaim cover the large majority of hand-written manifests. Other kinds still get full YAML syntax checking and deprecated-apiVersion detection — they just don't get schema-shape validation yet.
Does my YAML ever leave my browser?
No. Parsing and schema validation both run with plain JavaScript in this tab — the only network request this tool ever makes is fetching the public JSON Schema file for the resource kind and Kubernetes version you selected, never your manifest content.