Skip to content
Shrake DevTools
  • JSON FormatterData & Format
  • JSON ValidatorData & Format
  • JSON MinifierData & Format
  • JSON ↔ YAML ConverterData & Format
  • XML FormatterData & Format
  • Base64 Encoder / DecoderData & Format
  • URL Encoder / DecoderData & Format
  • JWT InspectorData & Format
↑ ↓ to navigate↵ to openEsc to close

Kubernetes YAML Validator

Validate Kubernetes manifests: YAML syntax, API versions, kinds, metadata and containers.

Runs locally in your browser. Your input is not uploaded.Free, no sign-up

Manifests

Paste manifests to validate them as you type, or click Sample to see common mistakes.

How to use the Kubernetes YAML Validator

  1. Paste one or more manifests separated by ---, or click Sample to see common mistakes.
  2. Problems are listed per manifest and underlined in the editor, with the line, the field path and how to fix it.
  3. Fix them until every manifest shows as valid, then apply with confidence.

What it checks

  • YAML syntax and duplicate keys
  • apiVersion and kind, including API versions removed in newer Kubernetes releases (for example Ingress extensions/v1beta1, removed in 1.22, and CronJob batch/v1beta1, removed in 1.25)
  • Names, namespaces, labels and annotations, including numbers where Kubernetes requires strings
  • Misspelled fields such as metdata or imag, with suggestions
  • Selectors that don't match the pod template's labels, so no pods would be managed
  • Containers: names, images, ports, env values that must be strings, and CPU/memory quantities like 256MB vs 256Mi
  • Job restart policies, CronJob schedules, Service ports, ConfigMap values, Secret Base64 data and Ingress v1 backends

Supported kinds include Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, CronJob, Pod, Service, ConfigMap, Secret, Ingress, HorizontalPodAutoscaler, PodDisruptionBudget, NetworkPolicy and RBAC. Custom resources get basic checks.

Frequently asked questions

Are my manifests uploaded?

No. Validation runs entirely in your browser. Manifests often contain internal hostnames, image registries and Secret data; they never leave your machine.

Is this the same as kubectl --dry-run=server?

No. A server-side dry run asks your cluster's API server, which also knows your CRDs, admission policies and cluster version. This validator needs no cluster and catches the most common mistakes before you get that far.

Does it check best practices like resource limits and probes?

It focuses on mistakes that make manifests fail or misbehave. Best-practice checks, like missing limits, probes, running as root or :latest tags, belong in the Kubernetes Manifest Analyzer.