Tool Overview

This tool checks a single Kubernetes YAML manifest for basic correctness. It parses the YAML, checks that required top-level fields exist, and runs simple checks for a few resource types (Deployment, Service, Pod, ConfigMap, Secret). It reports syntax and schema errors with line and column so you can fix them before applying the manifest to a cluster.

Invalid or incomplete manifests cause apply failures and wasted time. Finding missing fields or bad structure by hand is slow. This tool runs the checks as you edit and shows where each problem is. A related operation involves validating Helm charts as part of a similar workflow.

It is for developers and operators who work with Kubernetes YAML. You need basic knowledge of YAML and Kubernetes resources. No account or sign-in is required. For adjacent tasks, validating Docker Compose files addresses a complementary step.

Background and How the Tool Works

Kubernetes resources are often written as YAML. Each manifest usually has apiVersion, kind, and metadata, plus a spec or data section depending on the resource type. The cluster rejects manifests that are invalid YAML or that miss required fields. Catching these errors before apply saves time and avoids failed deployments. When working with related formats, validating YAML syntax can be a useful part of the process.

This tool parses your input as YAML with a single-document parser. If the input has multiple documents separated by a line with three dashes, only the first document is validated. It then checks that the root is an object and that apiVersion, kind, and metadata are present and that metadata.name exists. For Deployments it checks for spec, spec.selector, and spec.template. For Services it checks for spec.ports when spec exists. For Pods it checks for spec.containers. For ConfigMap and Secret it checks that data, when present, is an object. It also checks that apiVersion looks like a valid format (for example group/version or v1). It does not validate against the full Kubernetes API schema; it only runs these basic checks. In some workflows, validating Dockerfiles is a relevant follow-up operation.

People struggle when the cluster returns a generic error or when the manifest is long. The tool reports the first set of problems with line and column when available so you know where to look. For related processing needs, validating JSON syntax handles a complementary task.

Key Features

• Single input: One editor for your Kubernetes YAML. You paste or type the manifest. You can also upload a file. The tool validates the content as one YAML document. If you paste multiple documents separated by three dashes, only the first document is parsed and validated.
• Size limits: Input is limited to 500KB and 10,000 lines. Larger or longer input produces an error and validation stops.
• File upload: You can load a file from disk. Accepted types are .yaml and .yml. The file must be under 500KB. If the content is larger, only the first 500KB is loaded.
• Version selector: You can choose a Kubernetes version (for example 1.30, 1.29, 1.28, 1.27) from a dropdown. The result area can show the version you selected. The basic validation rules do not change by version; the selector is for reference.
• Automatic validation: When you change the YAML or the version, the tool runs validation after a short delay. You see valid or a list of issues without clicking a button.
• YAML syntax check: The tool parses the input as YAML. If parsing fails, it reports a syntax error and, when the parser provides it, the line and column of the problem.
• Root and required fields: The root must be a single object (mapping), not an array or a primitive. The tool checks that apiVersion, kind, and metadata exist and that metadata.name exists. Missing items are reported as schema errors.
• Resource-specific checks: For Deployment it checks for spec, spec.selector, and spec.template. For Service it checks for spec.ports when spec is present. For Pod it checks for spec.containers when spec is present. For ConfigMap and Secret it checks that data, when present, is an object. These are basic checks only; the tool does not validate every field against the Kubernetes API.
• apiVersion format: If apiVersion is present, the tool checks that it matches a simple pattern (group/version or v1). Invalid format is reported as a warning. Warnings do not make the result invalid.
• Result summary: You see either Valid or the number of issues. When the document parses, the tool shows the detected kind and name (for example Deployment: nginx-deployment).
• Error list: Each error has a message, line and column, and often a short suggestion. Errors have a type: syntax, schema, or warning. Only syntax and schema errors make the result invalid.
• Sample: A button loads a sample Deployment YAML so you can see a valid manifest and try changes.
• Copy and Clear: You can copy the editor content to the clipboard or clear the editor and start over.
• Get Fix: For each error you can click Get Fix. The tool sends the YAML and the error message to a backend service. You may get a short explanation and a suggested fixed YAML. You can copy the suggestion or apply it to replace the editor content. This feature may be unavailable or fail; use the error message and line information to fix problems when suggestions are not available.

Common Use Cases

You are writing or editing a Deployment, Service, or Pod manifest and want to catch missing fields and YAML errors before running kubectl apply. You paste the YAML into the tool and fix any reported issues. You use the sample to see a minimal valid Deployment. Before applying a manifest from a doc or script, you paste it here to check syntax and basic structure. When an error is unclear, you use Get Fix to get an explanation and suggested YAML if the service is available.

How to Use This Tool

1. Open the tool. You will see an editor on the left and a results area on the right.
2. Paste your Kubernetes YAML into the editor or click Sample to load an example Deployment. You can also click Upload and choose a .yaml or .yml file. Keep the content under 500KB and 10,000 lines.
3. Optionally select a Kubernetes version from the dropdown (for example 1.30). Validation runs automatically. Look at the results area: Valid or the number of issues, and the detected kind and name when the document parses.
4. If there are errors, read each message and the line and column. Fix the YAML in the editor. Common issues: invalid YAML syntax (indentation, colons, or structure); root not an object; missing apiVersion, kind, or metadata; missing metadata.name; for Deployment missing spec, spec.selector, or spec.template; for Service missing spec.ports; for Pod missing spec.containers; for ConfigMap or Secret data not an object. Warnings (for example invalid apiVersion format) do not make the result invalid but you can fix them.
5. Use Copy to copy the editor content. Use Clear to empty the editor. If you have multiple resources in one file, note that only the first document (before the first three-dash line) is validated.
6. Optional: for an error, click Get Fix. Wait for the explanation and suggested YAML. You can copy the suggestion or click Apply Fix to put it into the editor. If Get Fix fails, fix the error using the message and line number.

What Is Checked and What Is Not

The tool checks YAML syntax, root structure, and the presence of apiVersion, kind, metadata, and metadata.name. It runs basic checks for Deployment (spec, selector, template), Service (spec.ports), Pod (spec.containers), ConfigMap (data as object), and Secret (data as object). It warns when apiVersion does not match a simple group/version or v1 pattern. It does not validate against the full Kubernetes API schema. It does not check that resource names or labels are valid, that image names exist, or that the cluster will accept the manifest. For full validation use kubectl apply --dry-run=server or other Kubernetes tooling. Only one YAML document is validated; if you have multiple documents, only the first is used.

Reference: Checks Performed

Tips, Limitations and Best Practices

Keep the manifest under 500KB and 10,000 lines. Use the sample to see a valid structure. Ensure the root is a single YAML object with apiVersion, kind, and metadata at the top level. For multi-resource files, validate one document at a time or split the file.

The tool does not connect to a cluster. It does not check that the Kubernetes server will accept the manifest. Use kubectl apply --dry-run=server for server-side validation when possible. The version selector does not change validation rules; it is for reference only.

Get Fix sends your YAML and the error message to a backend service. Do not use it with secrets or sensitive data. If the service fails, use the error message and line and column to fix the problem by hand.