What counts as an error versus a warning?

Errors are structural problems that would break the file, like invalid YAML or a missing required field. Warnings flag things that parse fine but are likely mistakes, like a Compose service without an image or build key.

Does this validate against the full Kubernetes API schema?

No, it checks for required top-level fields (apiVersion, kind, metadata.name) and multi-document structure, not the complete OpenAPI schema Kubernetes itself validates against on apply.

Is my Compose file or manifest uploaded anywhere?

No, the YAML is parsed and checked in your browser using js-yaml, so service names, image references and any environment values in the file stay local.

Can it validate a Kubernetes file with multiple resources in one file?

Yes, Kubernetes mode parses multi-document YAML split by `---` and reports errors per document, labeling each as "Document 1", "Document 2" and so on.

Why does it flag the `version` key in my Compose file?

The Compose specification deprecated the top-level `version` field; recent versions of Docker Compose ignore it, so the validator flags it as an obsolete warning rather than an error.

Config Validator

Validate YAML, Docker Compose and Kubernetes manifests for structure and common mistakes, locally.

Local, Runs entirely in your browser, your data never leaves your device.

Loading tool…

Catch YAML, Compose and Kubernetes mistakes before you deploy

This tool parses YAML and checks it against rules specific to plain YAML, Docker Compose files or Kubernetes manifests, depending on which mode you pick. It catches the kind of mistake that only shows up at deploy time: a service with no image, a Kubernetes object missing metadata.name, or YAML that simply won't parse. Since config files often contain internal service names, ports or environment references, parsing stays in the browser and the file is never uploaded.

How to use the Config Validator

Choose a mode: plain YAML, Docker Compose, or Kubernetes.
Paste your config into the editor, or start from the loaded example.
Read the pass/fail banner and the list of errors and warnings below it.
Fix flagged lines and watch the report update as you edit.
Switch modes if you picked the wrong one; each mode loads its own example.

Kubernetes mode reads multi-document YAML separated by `---`, since a single manifest file commonly bundles a Deployment, a Service and a ConfigMap together, and reports issues per document.

This checks structure, not full schema conformance: for Compose it flags services missing both `image` and `build` and the obsolete top-level `version` key; for Kubernetes it flags missing `apiVersion`, `kind` or `metadata.name`. It won't catch every possible Kubernetes API validation error.

Frequently asked questions

What counts as an error versus a warning?: Errors are structural problems that would break the file, like invalid YAML or a missing required field. Warnings flag things that parse fine but are likely mistakes, like a Compose service without an image or build key.
Does this validate against the full Kubernetes API schema?: No, it checks for required top-level fields (apiVersion, kind, metadata.name) and multi-document structure, not the complete OpenAPI schema Kubernetes itself validates against on apply.
Is my Compose file or manifest uploaded anywhere?: No, the YAML is parsed and checked in your browser using js-yaml, so service names, image references and any environment values in the file stay local.
Can it validate a Kubernetes file with multiple resources in one file?: Yes, Kubernetes mode parses multi-document YAML split by `---` and reports errors per document, labeling each as "Document 1", "Document 2" and so on.
Why does it flag the `version` key in my Compose file?: The Compose specification deprecated the top-level `version` field; recent versions of Docker Compose ignore it, so the validator flags it as an obsolete warning rather than an error.