Kubernetes YAML Validator
Check Kubernetes manifests before they reach a cluster: YAML syntax errors with line and column, plus API-level problems kubectl would reject — removed apiVersions, kind/apiVersion mismatches, invalid RFC 1123 names, selectors that don't match their pod template labels, unquoted ConfigMap values, missing pathType on an Ingress — and production warnings like :latest images and missing resource limits. Multi-document files supported. Runs entirely in your browser; nothing is uploaded.
Input
Output
| Severity | Resource | Path | Message |
|---|---|---|---|
| No data yet | |||
Guides
Paste a Kubernetes manifest and find out what's wrong with it before kubectl apply does. The validator checks two separate things: whether the YAML parses at all, and whether the resulting object is a manifest the API server will actually accept.
Multi-document files (--- separated) are supported, and everything runs in your browser — manifests are never uploaded, so it's safe to paste something out of a private repo.
How to use it
- Paste your manifest, or upload a
.yaml/.ymlfile. - Pick a validation profile.
- Read the Findings table — severity, which resource, the exact field path, and what's wrong. Download it as CSV if you want to work through it in a ticket.
The three profiles
- Basic — blocking errors only. These are the things the API server rejects outright: a removed
apiVersion, a missingmetadata.name, a selector that doesn't match its pod template. - Balanced (default) — errors plus warnings. Adds the problems that apply cleanly but bite later:
:latestimage tags, containers with no resource requests,hostNetwork: true. - Strict production — everything, including hardening checks.
runAsNonRoot,allowPrivilegeEscalation, read-only root filesystems, liveness probes, missingapp.kubernetes.io/namelabels, single-replica Deployments, default service accounts.
What it checks
Syntax — every YAML parse error in the file, each with its line and column, rather than stopping at the first one.
Resource identity — apiVersion and kind present; kind served by that apiVersion (a Deployment under apiVersion: v1 is caught); apiVersions that have been removed from the API, with the group/version that replaced them (extensions/v1beta1, apps/v1beta2, batch/v1beta1, autoscaling/v2beta2, policy/v1beta1 and the rest); RFC 1123 name validity; namespaces on cluster-scoped kinds; duplicate kind/namespace/name pairs within one file.
Workloads — required spec.selector and spec.template; selector labels that don't appear on the pod template (a real API-server rejection that is easy to miss by eye); serviceName on a StatefulSet; a five-field or @shortcut schedule on a CronJob; container names, images, image tags, duplicate container names; resource quantities that aren't valid quantities; container ports outside 1–65535; privileged containers and host namespace sharing.
Other kinds — Service type and port validity, and the "every port must be named when there is more than one" rule; ConfigMap values that are numbers or booleans instead of quoted strings; Secret data that isn't valid base64, and plaintext stringData; Ingress paths missing the pathType that networking.k8s.io/v1 requires; PVC access modes and storage requests; HPA scaleTargetRef and a minReplicas above maxReplicas.
Does it validate against the real Kubernetes OpenAPI schema?
No, deliberately. The full schema bundle is several megabytes per minor version and is tied to a cluster version you'd have to pick in advance — and it still can't express the checks that catch most broken manifests, like a selector that doesn't match its template labels. This tool ships a targeted rule set instead, which is why it runs instantly in the browser with nothing to install.
Is my manifest sent anywhere?
No. Parsing and validation both happen in your browser. There is no cluster connection, no upload, and no account.
Why does a valid manifest still show warnings?
Because "the API server will accept this" and "you should deploy this" aren't the same question. Switch to the Basic profile if you only want the blocking errors.
Related tools
Once the manifest is clean, the Kubernetes YAML Formatter re-indents it and sorts keys into the conventional apiVersion → kind → metadata → spec order. For plain YAML with no Kubernetes rules applied, use the YAML Validator. To build ConfigMaps and Secrets rather than check them, see the Kubernetes ConfigMap & Secret Generator.