Kubernetes YAML Validator

Paste one or more Kubernetes manifests and get an instant report. The validator checks YAML syntax first, then the fields that most often break kubectl apply: apiVersion and kind, metadata names, label types, container images, selectors, Service ports, and more.

Kubernetes manifest(s)

Related tools

What is checked

  • YAML syntax: indentation, tabs, duplicate keys, unclosed quotes, with the failing line highlighted.
  • Required fields: apiVersion, kind, metadata, and metadata.name, including case-sensitivity mistakes like apiversion.
  • Name formats: names must be lowercase DNS subdomains; namespaces must be DNS labels of 63 characters or fewer.
  • Labels and annotations: every value must be a string.
  • Removed apiVersions: extensions/v1beta1 Deployments, pre-1.22 Ingress versions, and batch/v1beta1 CronJobs are flagged.
  • Pod templates: containers must have a name and image; duplicate container names, missing containerPort numbers, unquoted env values, and unpinned :latest images are reported.
  • Workload selectors: spec.selector.matchLabels must match spec.template.metadata.labels, the single most common reason a Deployment is rejected.
  • Services: spec.ports entries need numeric ports, and a missing selector is flagged.
  • ConfigMaps and Secrets: data values must be strings, and Secret data must be base64.

Example: a Deployment with three mistakes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    version: 1.0        # number, must be a string
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: website    # does not match selector
    spec:
      containers:
        - name: web
          image: nginx  # no tag
          env:
            - name: PORT
              value: 80 # number, must be a string

Click Load sample above to see how these are reported. Fixing them is usually a matter of adding quotes and making the labels agree.

Why manifests fail even when the YAML is valid

A Kubernetes manifest can be perfectly valid YAML and still be rejected by the API server, because Kubernetes has its own rules about types and required fields on top of the YAML grammar. The classic examples are numeric label values, selectors that do not match the pod template, and apiVersions that were removed several releases ago. This tool sits between a plain YAML validator and a full cluster dry run so you can catch those problems before you commit.

Frequently asked questions

Does this validate against the full Kubernetes OpenAPI schema?

No. It checks YAML syntax plus the structural rules that catch the large majority of real mistakes: required top-level fields, name formats, label types, container definitions, selector/label agreement, Service ports, and removed apiVersions. For exhaustive schema validation run kubectl apply --dry-run=server -f file.yaml against a cluster, or use kubeconform offline.

Which resource kinds get extra checks?

Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, CronJob, Service, ConfigMap, and Secret. Every other kind still gets the generic checks for apiVersion, kind, and metadata.

Can I validate a file with several manifests?

Yes. Separate them with --- as you would for kubectl apply. Each document is validated independently and reported by its position, kind, and name.

Why does it complain that my label value must be a string?

Kubernetes requires label and annotation values to be strings, but YAML parses version: 1.0 as a number, so the API server rejects it. Quote the value: version: "1.0". Learn more about this in the YAML parser.

Is my manifest sent to a server?

No. Everything runs in your browser. Manifests containing Secrets or internal hostnames never leave your machine.