Kubernetes YAML Validator
Validate Kubernetes manifests against the real Kubernetes API schema for Deployment, Service, Pod, ConfigMap, and Ingress — not just generic YAML syntax.
Validate Kubernetes Manifests Against Their Real Schema
Generic YAML validation only checks that a file parses — it can't tell you that spec.replicas needs to be a number, or that a Service is missing its selector. This tool goes a level deeper: it reads each document's apiVersion and kind, matches it to the corresponding Kubernetes schema, and validates the whole manifest against it.
It currently covers five common resource kinds — Deployment, Service, Pod, ConfigMap, and Ingress — rather than the full Kubernetes API surface. Syntax is checked first; schema validation only runs on documents that parse cleanly, and a document with an unrecognized apiVersion/kind combination (a CRD, or a kind outside this list) is flagged distinctly instead of being silently skipped or misreported as a schema violation.
Paste a manifest — or drag and drop a .yaml/.yml file — and every---separated document in it is validated independently, entirely in your browser. Nothing is uploaded to a server.
Why Validate Against the Kubernetes Schema?
Catch Mistakes Before kubectl apply
A string where an integer belongs, or a missing required field, parses as valid YAML but fails at the API server. This catches it first, locally.
Review Manifests in CI Without a Cluster
Schema-check a Deployment or Ingress in a PR or pipeline step without needing kubectl, a kubeconfig, or a live cluster to validate against.
Learn the Shape of a Resource
The path-and-message report doubles as a quick way to see exactly which field is wrong and where it lives in the manifest.
Catch Custom Resources Explicitly
CRDs and less common kinds are flagged as unrecognized rather than silently passed or misvalidated against the wrong schema.
Example
A multi-document manifest bundling a Deployment, Service, and ConfigMap — each validated against its own schema, with a per-document report.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
ports:
- port: 80
targetPort: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
data:
NODE_ENV: production
LOG_LEVEL: info[Doc 1] Deployment "web" — Valid
[Doc 2] Service "web-service" — Valid
[Doc 3] ConfigMap "web-config" — ValidFeatures
Real Kubernetes Schemas
Validates against schemas derived from the Kubernetes OpenAPI spec, not just generic YAML syntax.
Multi-Document Manifests
A ---separated file bundling a Deployment, Service, and ConfigMap is validated document by document.
Schema Path + Message
Every violation is reported with its JSON pointer path (e.g. /spec/replicas) and a human-readable message.
Unrecognized Kinds Flagged
A CRD or unsupported kind is called out distinctly from a real schema violation, not silently skipped or misreported.
Syntax Errors First
YAML syntax is checked before schema validation runs, so a typo is reported plainly instead of a confusing schema error.
Clear Pass/Fail Report
Copy or download a per-document report listing every issue found across the whole file.