Kubernetes Manifest Linter

Step-by-step guide

1. 1
   Paste your Kubernetes manifest
   Copy a YAML manifest from your codebase or terminal and paste it into the editor. Multi-document YAML files separated by --- are supported.
2. 2
   Select the Kubernetes version
   Choose the API version you are targeting (e.g. 1.28, 1.29, 1.30) so the linter applies the correct schema rules for that release.
3. 3
   Run the linter
   Click Validate or trigger automatic validation. The tool parses the YAML and checks each resource against its Kubernetes API schema.
4. 4
   Review errors and warnings
   Issues are listed with the resource kind, the field path, and a human-readable explanation. Errors indicate invalid config; warnings flag best-practice violations.
5. 5
   Fix and re-validate
   Edit the manifest in the panel, then re-validate to confirm all issues are resolved before committing the file or applying it to a cluster.

Frequently Asked Questions

What does a Kubernetes YAML linter check?

A Kubernetes YAML linter checks that a manifest conforms to the Kubernetes API schema for the given resource kind and API version. This includes: required fields (e.g. metadata.name, spec.containers), field types (e.g. a port number must be an integer), valid enum values (e.g. restartPolicy must be Always, OnFailure, or Never), and structural rules specific to each resource kind.

Why should I validate manifests before applying them?

kubectl apply will reject invalid manifests at apply time, often with cryptic error messages. Validating locally before a cluster apply surfaces issues immediately: without needing cluster access: and makes them much easier to diagnose. This is especially valuable in CI pipelines where a failed apply can block a deployment.

Does the linter catch all possible Kubernetes errors?

The linter catches schema-level errors: missing required fields, wrong types, and invalid enum values. It does not catch semantic or runtime errors such as referencing a non-existent Secret, requesting more resources than available nodes can provide, or misconfigured RBAC policies. Those require a running cluster to detect.

What resource kinds are supported?

All core Kubernetes resource kinds are supported, including Pod, Deployment, StatefulSet, DaemonSet, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim, ServiceAccount, Role, ClusterRole, RoleBinding, ClusterRoleBinding, Job, CronJob, and HorizontalPodAutoscaler. Custom Resource Definitions (CRDs) are not validated against a schema since they require the CRD definition itself.

How does this tool handle multi-document YAML files?

YAML files with multiple documents separated by --- are fully supported. Each document is validated independently against its own kind and apiVersion. Results are grouped by document so you can identify which manifest in a bundle has an issue.

Can I validate Helm chart templates?

Helm templates contain Go template syntax ({{ .Values.foo }}) that is not valid YAML until rendered. You need to run helm template first to produce the rendered manifests, then paste the output into this tool for validation.

Is my manifest data sent to a server?

No. All YAML parsing and schema validation runs entirely in your browser using a bundled schema library. Your manifests: which may contain service names, image paths, or environment variable keys: are never transmitted to any external server.

What common misconfigurations does the linter catch?

Common issues flagged include: containers array being empty or missing, image field not set on a container, missing selector or template labels in a Deployment, invalid CPU or memory resource format (e.g. 500mb instead of 500Mi), containerPort not being an integer, and apiVersion or kind values that do not exist in the target Kubernetes version.

Should I also run kubeval or kube-score?

This browser tool is designed for quick checks during development. For comprehensive CI validation, tools like kubeval, kube-score, kubelint, or Datree offer additional policy checks, best-practice rules, and CRD support. This tool complements them as a fast, zero-install first pass.

Can the linter check namespace and label conventions?

The linter checks that namespace is a valid string and that label values conform to Kubernetes label syntax (alphanumeric, hyphens, underscores, dots, max 63 characters). It does not enforce custom naming conventions specific to your organisation: those are better enforced via OPA/Gatekeeper policies on the cluster.