Helm Values Schema Validator

values.yaml:

Paste YAML, drop one YAML file, or load a local file up to 2 MiB.

{{ valuesFileError || valuesFileStatus || 'Drop YAML or TXT onto the textarea.' }}

Validation profile:

The profile changes hygiene severity, not JSON Schema pass or fail behavior.

values.schema.json:

Use a JSON Schema object compatible with the chart's Helm version.

{{ schemaFileError || schemaFileStatus || 'Drop JSON or TXT onto the textarea.' }}

Command target:

This choice changes the generated shell artifact, not browser-side validation.

Property descriptions:

This maintainability policy is visible because it changes findings.

Open object policy:

Deliberately open maps can stay open; the finding prompts an explicit review.

{{ warnOpenObjectsBool ? 'Report open objects' : 'Do not report' }}

Finding row limit:

5 rows{{ safeErrorLimit }} rows200 rows

The default 50-row view keeps large failure sets readable.

Status	Area	Metric	Value	Evidence	Copy
{{ row.status }}	{{ row.area }}	{{ row.metric }}	{{ row.value }}	{{ row.evidence }}

Validation report

Severity	Issue	Location	Evidence	Recommended action	Copy
No validation or hygiene findings for the current sources.
{{ row.severity }}	{{ row.issue }}	{{ row.path }}	{{ row.evidence }}	{{ row.action }}

Schema path	Type	Required	Values status	Evidence	Copy
{{ row.path }}	{{ row.type }}	{{ row.required }}	{{ row.status }}	{{ row.evidence }}

{{ ciSnippet }}

A Helm chart can render successfully with configuration that is misspelled, incomplete, or unsafe for the workload. The chart's values.yaml supplies defaults and user-facing settings, while values.schema.json can describe which keys are allowed, which are required, and what type or range each value must satisfy.

Schema validation catches errors before templates turn them into Kubernetes manifests. A string where an integer is expected, an omitted required key, an extra property in a closed object, or a value outside an allowed range can stop a release before the cluster sees it. That is different from template validation, which checks the rendered output, and from server-side admission, which applies cluster policy and API rules.

Helm values review layers and the questions they answer
Review	Question answered	Important limit
YAML parse	Can the values text be read as YAML?	Valid YAML can still have the wrong shape or meaning.
JSON Schema validation	Do the parsed values satisfy declared rules?	The schema cannot check rules it does not express.
Template rendering	Can Helm produce manifests from the chart and values?	Rendered manifests may still fail cluster policy or runtime expectations.
Cluster dry run or admission	Will the target API accept the manifests?	Acceptance does not prove the workload will become healthy.

Coverage and validity should not be confused. A values file can pass because the root schema is open, even though several top-level keys are absent from properties. Conversely, a complete schema can reject an intentional override because the chart author forgot to update a type, enum, or required list. The schema and the chart defaults must evolve together.

Maintainability rules add another distinction. Property descriptions, explicit additionalProperties choices, and locally available references make a schema easier to review and reproduce, but they are not all Helm pass-or-fail rules. A useful gate keeps blocking validation errors separate from hygiene warnings.

Passing one values file proves only that one configuration satisfies the supplied schema. It does not prove that every supported override works, that the rendered manifests are valid for a target cluster, or that the deployed release is safe. CI should combine schema validation with Helm linting, template rendering, and the environment-specific checks that matter to the chart.

How to Use This Tool:

Review the exact values and schema that will travel together in the chart. Normalizing or formatting text can help inspection, but it should not replace the version-controlled source.

Paste or load values.yaml, then confirm that its root is a mapping rather than a list or scalar.
Choose a Validation profile. The profile changes the severity of maintainability findings, not whether JSON Schema validation passes.
Paste values.schema.json from the same chart revision. Use a schema compatible with the Helm version in the intended CI or release path.
Review Gate for parse, compile, and schema-validation failures. Fix Error findings before treating the configuration as valid.
Inspect Paths and Issues for uncovered root keys, missing required properties, open object policy, missing descriptions, and remote references.
Select the Command target that matches the next check, then run the generated command in the real chart checkout after the browser review is clean.

Interpreting Results:

Error means YAML or JSON could not be parsed, the schema could not be compiled, or the values failed a schema rule. Warning means the blocking gate passed but the selected hygiene policy found a maintainability or reproducibility concern. Pass means neither Error nor Warning findings remain; Info findings may still explain defaults or other non-blocking facts.

Treat root coverage as a review clue, not a validity score. One undeclared top-level key can matter more than a high percentage, and nested properties have their own coverage rows. Confirm a clean result with the generated Helm command because the browser does not render the chart or contact a Kubernetes cluster.

Technical Details:

The validation starts by parsing YAML into a value tree and parsing the schema as JSON. The values root should be an object because Helm exposes chart configuration as a mapping. The schema is then compiled with draft-07-compatible behavior without applying defaults, coercing types, or removing unknown fields.

Rule Core

Blocking validity and advisory hygiene follow separate paths.

Reject invalid YAML, invalid JSON, a non-object schema root, or a schema that cannot compile.
Validate the parsed values against the compiled schema. Keywords such as type, required, minimum, enum, and additionalProperties can produce Error findings.
Compare root values keys with root properties. Undeclared keys become hygiene findings only when the root remains open; a closed root is already enforced by schema validation.
Count required schema properties that are absent, object schemas whose unknown-key policy is implicit, and property schemas without descriptions.
Report schema default values as annotations rather than mutations, and flag remote references because unavailable dependencies can make CI nondeterministic.

Helm validation profile effects
Finding class	Helm CI or schema authoring	Override review
Parse, compile, or schema failure	Error	Error
Uncovered open-root key	Warning	Info
Implicitly open object	Warning when enabled	Info when enabled
Missing property description	Warning when required	Info when required

Formula Core

Root coverage measures how many top-level keys in the parsed values are declared under the schema's root properties. An empty values mapping is defined as 100% covered because it has no uncovered root keys.

C = \frac{K_{covered}}{K_{total}} \times 100 %

The canonical value retains six decimal places. Display surfaces may show a shorter percentage. Coverage does not include every nested rule and does not replace the schema engine's valid or invalid result.

Input Boundaries

Each text input is limited to 2 MiB. The rendered finding limit accepts 5 through 200 rows and truncates only the visible ledger, not the underlying validation count. The command choice changes the generated shell instructions; it does not change browser-side schema validation.

Limitations and Privacy Notes:

The values and schema are read in the browser and no cluster is contacted. Avoid pasting secrets anyway: values files commonly contain credentials, tokens, private image locations, and internal hostnames that may also be copied into reports or shell history.

Run the selected Helm command against the intended chart and Helm version before merge or release.
Remote schema references may not be available in every CI environment; vendoring them improves repeatability.
A valid schema cannot detect unsafe templates, deprecated Kubernetes APIs, admission-policy failures, or runtime health problems unless those facts are expressed as values rules.
Hygiene findings are configurable review policy, not requirements imposed by JSON Schema or Helm.

Worked Examples:

A value that looks reasonable but fails the contract

If replicaCount is written as the string "2" while the schema requires an integer, validation returns an Error even though a template might appear able to print it. If an image object also omits its required tag and adds an unknown extra key under a closed schema, those are separate Error findings. Correct the values or deliberately revise the schema, then rerun Helm lint and template rendering.

References:

Charts: Schema Files, Helm.
Values Best Practices, Helm.
JSON Schema Draft 7, JSON Schema.
How to install a Helm chart on Kubernetes, Simplified Guide.