Kubernetes / Helm
Choose a Kubernetes snapshot, inspect field diagnostics and export the resource you need.
Result is out of date; export is disabled.
Manifests and custom schemas stay in this browser; no cluster connection.
Result is out of date; export is disabled.
Static checks do not guarantee deployment. Formatted YAML can be exported with validation errors; review diagnostics first.
Use this Kubernetes YAML validator when a review contains several resources and a plain YAML parser says only that the syntax is legal. A valid mapping can still put a string where replicas expects an integer or misspell a container field.
Keep the target cluster version visible during Kubernetes manifest validation. The bundled snapshots are 1.35.0, 1.36.0 and 1.37.0; the result describes that schema snapshot and the current input, not a request sent to an API server.
The Kubernetes YAML validator lists each document with its kind, name and namespace. Field diagnostics keep their document number and source position, so a Service error is not confused with the Deployment next to it. Select a resource to extract its formatted YAML while the complete input stays intact.
A Service selector is compared with Pod labels and workload template labels in the same namespace. ConfigMap and Secret references are checked against the supplied resources. A missing match is a warning because the object may already exist in your cluster.
The default is 1.37.0. Changing the snapshot, indentation or custom schema makes the old result stale immediately. Run validation explicitly with the button or Ctrl/Cmd+Enter; there is no background auto-validation.
Open the custom schema panel and enter the exact apiVersion and kind alongside draft-07 JSON Schema. Internal references are supported. Missing external references cause an error; neither CRD discovery nor a remote schema download is performed.
Formatting and file merging create a preview with character and document counts. Apply writes it back; Undo restores the input and the previous result together. Choose All documents or one numbered resource for the next export.
Kubernetes schema validation uses the complete definitions from the pinned upstream registry, derived from Kubernetes OpenAPI. Strict schemas detect additional fields, required values and wrong types. The workbench reports the first schema violation per resource, so correcting one error can reveal another.
Common resource names receive DNS checks; RBAC names use path-segment rules. Duplicate identity compares API group, kind, namespace and name, ignoring the API version. Unsupported kind-specific name rules remain visible as warnings. Job names are limited to 63 characters and CronJob names to 52.
The local check covers Service selectors plus ConfigMap and Secret references in container environments, volumes and projected volumes. Workload templates are inspected too. It does not test connectivity, discover external objects or determine whether referenced keys exist.
Validate multi-document YAML without flattening it through JSON. Formatting preserves comments and numeric source text. Selected-document export and local file merging share the same parser, with no automatic sorting or field deletion.
Separate syntax checking from resource validation. This Kubernetes YAML validator parses every document, identifies apiVersion/kind and checks the corresponding bundled schema. Correct reported fields, then use your cluster’s own validation process for admission and environment-specific decisions.
Choose 1.35.0, 1.36.0 or 1.37.0. Older versions such as the 1.20 mentioned in the source question are not bundled. Use a validator with the exact older schema rather than assuming a newer snapshot is equivalent.
Provide the custom kind’s draft-07 schema and exact apiVersion/kind in the custom panel. A resource without a matching schema is marked for review. Constraints expressed only as Kubernetes extensions, including CEL, still require the appropriate server or policy tooling.
Yes. Use --- between resources, up to 100 documents. Each nonempty document appears separately in the list. A List object is a different structure and is intentionally reported as unsupported rather than treating its items as separate documents.
YAML can interpret unquoted true or a numeric value as a boolean or number. Kubernetes label values are strings. Quote the intended text, such as "true" or "123", and validate again. Formatting alone does not coerce the value.
Found a configuration this tool handles incorrectly?
Keep Kubernetes YAML validator findings alongside the deployment review. Recheck after changing a version or field, then export the exact document set you intend to use.