Kubernetes Manifest Validator

Check Pod, Deployment, Service, ConfigMap, Secret, Ingress, Job, and CronJob YAML for required fields and structural errors. Multi-document files supported. Runs entirely in your browser.

Manifest YAML

Validation Result

What is a Kubernetes manifest validator?

A Kubernetes validator reads YAML manifests, confirms the document is well-formed, and verifies that each Kubernetes kind has the fields it needs to be admitted by the API server. This catches the easy mistakes — missing apiVersion, an empty spec.containers, a Service with no ports — before kubectl apply rejects them.

It is not a replacement for kubectl --dry-run=server or kubeval; those validate against the live API or the full OpenAPI schema. This validator is the fast feedback loop that lives in your browser — paste, validate, fix, repeat.

How to validate a Kubernetes manifest — 4 steps

Paste the manifest. A single document or a multi-document file (--- separated). Click Load Sample to try a Deployment + Service.
Click Validate. The parser splits documents, parses each one, and runs structural checks per kind.
Read the issues. Each issue lists a document index, a path (e.g. spec.containers[0].image), and the reason.
Fix and re-run. Iterate until the result is clean — then run kubectl apply --dry-run=server for the final check.

Sample manifest and result

Input

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  template:
    spec:
      containers:
        - image: nginx:1.25

Result

Found 2 errors, 0 warnings across 1 document.

[ERROR] doc #1  spec.selector.matchLabels — Deployment requires spec.selector.matchLabels.
[ERROR] doc #1  spec.template.spec.containers[0].name — Container at index 0 is missing "name".

Kind-Aware Checks

Pod, Deployment, StatefulSet, DaemonSet, Service, ConfigMap, Secret, Ingress, Job, CronJob — each gets the structural checks Kubernetes itself would enforce.

Multi-Document

Helm, kustomize, and hand-written bundles use --- to separate manifests. Every document is validated independently.

Browser-Local

Manifests with image registry credentials, internal hostnames, and proprietary labels never touch a server.

Use cases

check_circleIaC review: catch missing fields before kubectl apply during code review
check_circleCI lint step: pipe Helm or kustomize output through the validator before deploy
check_circleGitOps: validate manifests in pull requests before ArgoCD/Flux syncs them
check_circleOnboarding: surface common mistakes for engineers learning Kubernetes
check_circleLocal development: paste from your editor without leaving the browser
check_circleAuditing third-party charts: scan vendor-provided YAML for missing fields

HCL vs JSON vs YAML for IaC

Aspect	YAML (Kubernetes)	HCL (Terraform)	JSON
Used by	K8s, Helm, kustomize	Terraform, Packer	CloudFormation (also)
Indentation-sensitive	Yes (fragile)	No	No
Multi-doc support	--- separator	N/A	JSON Lines
Schema validation	CRD / OpenAPI	Provider-driven	JSON Schema
Best for	Declarative state	Resource graphs	Generated configs

More IaC-friendly tools

Validate, convert, and lint your infrastructure files — all browser-side.

Dockerfile Validator YAML Validator HCL to JSON

Frequently Asked Questions

What does this Kubernetes validator check?

It parses each YAML document, confirms top-level apiVersion / kind / metadata.name, and runs kind-specific structural checks: Pod requires spec.containers with name + image, Deployment requires spec.selector.matchLabels and spec.template.spec.containers, Service requires spec.ports, ConfigMap/Secret should have data or stringData, Ingress requires spec.rules, Job requires template containers, CronJob requires schedule + jobTemplate containers.

Does it replace kubectl --dry-run or kubeval?

No. This is a structural sanity check that runs in the browser without a cluster connection. kubectl --dry-run validates against the live API server (including admission controllers and CRDs); kubeval validates against the full OpenAPI schema for a specific Kubernetes version. Use this tool to catch the most common mistakes early; reach for kubectl/kubeval before merging to production.

How does it handle multi-document YAML?

Documents separated by --- are validated independently. Each issue reports its document index (doc #1, doc #2…) so you can locate the manifest in a long file or Helm-rendered output.

What kinds are supported?

Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, Service, ConfigMap, Secret, Ingress, Job, CronJob. Other kinds — including Custom Resources — pass the generic apiVersion / kind / name check but receive no kind-specific validation. For full CRD validation, use a schema-aware tool.

My manifest works in production but the validator complains — why?

Two possibilities. First, the validator runs a static structural check; if your manifest relies on kubectl apply --strategic-merge or admission webhooks to fill in fields, the static view will look incomplete. Second, parsing of complex YAML (anchors, aliases, multi-line scalars, very deep indentation) is approximate — paste a single document if a multi-doc file confuses the parser.

Is my manifest uploaded?

No. Parsing and validation run in JavaScript inside your browser. Manifests with secrets, registry credentials, internal hostnames, or proprietary configuration never leave the device. Verify in DevTools → Network — clicking Validate makes zero requests.

Can it validate Helm chart output?

Yes. Run helm template my-chart > rendered.yaml, paste rendered.yaml here, and the validator will check every document in the bundle. Helm subchart hooks and CRDs that lack a registered schema will pass the generic check.

How is this different from a YAML validator?

A YAML validator only confirms syntax — that the document parses. This Kubernetes validator goes further: it understands what fields each Kubernetes kind needs, so it catches missing apiVersion, missing containers, missing selector, and so on. Always start with valid YAML; this tool checks the next layer up.