Kubernetes YAML Validator
Validate Kubernetes manifests against the real Kubernetes API schema for Deployment, Service, Pod, ConfigMap, and Ingress — not just generic YAML syntax.
Related Tools
Learn more about the Kubernetes YAML Validator
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.
How to use
Paste your input in the left editor. The output appears automatically on the right. Use the toolbar buttons to copy, download, or transform the result.
- Paste or type your content in the input editor on the left.
- The formatted output is generated automatically.
- Use Copy, Download, or other actions from the output toolbar.
- Click the expand icon to view the output in fullscreen.
FAQ
Is this Kubernetes YAML validator free?
Yes, it is completely free to use with no limits, signup, or account required.
Is my manifest uploaded to a server?
No. All validation happens entirely in your browser using JavaScript. Your manifest is never uploaded or sent to a server.
Which resource kinds are covered?
Deployment (apps/v1), Service (v1), Pod (v1), ConfigMap (v1), and Ingress (networking.k8s.io/v1) — a fixed set of common kinds rather than the full Kubernetes API surface.
How is this different from the generic YAML Validator?
The YAML Validator checks syntax, duplicate keys, and tab indentation — it has no idea what a Deployment is supposed to look like. This tool reads apiVersion and kind, matches the document to its real Kubernetes schema, and validates fields, types, and required properties against it. Syntax is still checked first; schema validation only runs on documents that parse cleanly.
What happens with a CRD or a kind this tool doesn’t cover?
It’s flagged as "Unrecognized Kind" — a distinct case from a schema violation — rather than being silently skipped or validated against the wrong schema.
Does it support multi-document manifests?
Yes. A ---separated file — a Deployment, Service, and ConfigMap bundled together, for example — is validated one document at a time, so an issue in one doesn’t hide issues in the others.
What does a violation look like?
Each one includes the JSON pointer path to the offending field (e.g. /spec/replicas) and a human-readable message, such as "must be integer".
Can I upload a file instead of pasting?
Yes. Drag and drop or use the upload button to load a .yaml/.yml file.
Can I copy or download the validation report?
Yes, use Copy Report or Download Report to get a plain-text summary of every document and issue found.