Validate Kubernetes YAML manifests for syntax and common structural issues before applying resources to a Kubernetes cluster.
Parse Kubernetes YAML and check common manifest structure and configuration issues before using it with your cluster.
Supports multiple documents separated by ---
Your support helps us build more tools and improve the ones you already use.
More tools you may find useful.
Analyze Kubernetes manifests to inspect resources, workloads, replicas, containers, images, labels, selectors, references, and common configuration issues.
Compare Kubernetes YAML manifests and identify added, removed, and modified resources and configuration fields between two versions.
Generate Kubernetes Secret manifests with Base64-encoded values for passwords, tokens, keys, and other configuration data.
Convert Kubernetes CPU and memory quantities between millicores, cores, bytes, decimal units, and binary units.
ToolTunnel Kubernetes YAML Validator is a browser-based tool for parsing Kubernetes YAML manifests and checking common structural and configuration problems. It supports multiple YAML documents, reports YAML parsing errors with line and column information when available, and performs resource-specific checks for common Kubernetes objects such as Deployments, Services, Pods, ConfigMaps, and Secrets.
Kubernetes resources are commonly described using YAML manifests. A manifest defines the desired configuration of an object such as a Deployment, Service, Pod, ConfigMap, Secret, Job, or other Kubernetes resource.
Because YAML is indentation-sensitive and Kubernetes resources follow specific structural conventions, a small syntax or configuration mistake can prevent a manifest from being parsed or accepted by Kubernetes.
The validator first parses the YAML and then performs additional checks based on the resource kind. It can process multiple YAML documents separated by the YAML document marker (---).
The checks are intended to catch common problems before you copy a manifest into kubectl, a deployment pipeline, GitOps workflow, or another Kubernetes management system.
The validator includes targeted checks for several commonly used Kubernetes resource kinds. These checks are designed to provide useful feedback without attempting to reproduce the entire Kubernetes API server validation process.
Before resource-specific validation can occur, the YAML must be parsed successfully. YAML syntax errors can result from incorrect indentation, malformed mappings, invalid sequences, or other syntax problems.
When the YAML parser provides location information, the validator reports the affected line and column so you can locate the problem more quickly.
Deployments are one of the most common Kubernetes workload resources. The validator checks common Deployment structure including apiVersion, spec, selector, pod template, containers, and replica configuration.
It also checks that container names and images are present and that container-related fields such as ports, environment variables, commands, and arguments use the expected array structure.
For Kubernetes Services, the validator checks the common structure of the Service specification and validates service ports. It also checks selector and type fields when they are present.
Pod validation focuses on the core pod specification and its containers. The validator checks that a pod has a valid spec and at least one container.
Each container is checked for a required name and image. Common array-based fields are also checked for the expected structure.
ConfigMaps and Secrets commonly store configuration values and application data. The validator checks the structure of data and stringData fields when they are present.
It also reports an informational warning when neither data nor stringData is defined.
Kubernetes configuration files often contain multiple resources separated by --- markers. The validator supports multiple YAML documents and displays the validation result for each parsed resource separately.
Each document receives its own resource identification, issue list, and parsed structure so that problems can be associated with the correct manifest.
The validator separates findings into errors, warnings, and informational messages. Errors generally represent structural or value problems that should be corrected, while warnings highlight configurations that may need attention.
Informational messages can indicate that a resource kind does not currently have specialized checks implemented by the tool.
Passing this validator does not guarantee that Kubernetes will accept or successfully deploy the resource. The Kubernetes API server performs additional validation that depends on the resource schema and Kubernetes version.
Admission controllers, admission policies, RBAC permissions, referenced resources, CRDs, namespace state, image availability, scheduling constraints, and cluster-specific configuration can introduce additional requirements.
This tool should therefore be treated as a fast pre-check rather than a replacement for kubectl validation, server-side validation, or testing against a real Kubernetes cluster.
The validator processes YAML in your browser. The YAML is not uploaded to a backend service by this tool.
This can be useful when reviewing configuration files locally. However, you should still follow your organization's security policies when handling secrets, credentials, private configuration, or other sensitive Kubernetes data.
A Kubernetes YAML Validator parses Kubernetes YAML manifests and checks them for common syntax, structural, and configuration problems before they are used with Kubernetes.
Yes. The tool first parses the YAML and reports YAML syntax errors. When available, parsing errors include the affected line and column.
No. It performs targeted checks for common resource types and structures. It does not reproduce all Kubernetes API server, admission controller, cluster, or CRD validation.
The current resource-specific checks cover Deployment, Service, Pod, ConfigMap, and Secret. Other resource kinds can still be parsed, but they may receive an informational message instead of kind-specific validation.
Yes. Multiple YAML documents separated by --- are supported, and each parsed document is reported separately.
Kubernetes resources generally need a resource name under metadata.name so that the object can be identified. The validator checks that metadata.name exists and is a non-empty string.
The validator expects spec.replicas to be a non-negative integer when the field is provided. For example, replicas: 3 is valid for this check, while replicas: "three" is not.
Yes. For supported workload resources, containers are checked to ensure that a non-empty image value is provided.
Not completely. It performs selected structural and configuration checks rather than loading the complete Kubernetes OpenAPI schema for every resource and Kubernetes version.
Yes. You can open a .yaml or .yml file directly from your device or drag and drop it into the input area.
No. The validator processes the YAML locally in your browser and does not upload it to a backend service.
No. It is intended as a convenient pre-check. Kubernetes server-side validation, admission policies, cluster configuration, permissions, referenced resources, and other runtime conditions can identify additional problems.
An informational message can indicate that the YAML parsed successfully but the resource kind does not currently have specialized validation checks implemented by this tool.