Helm Values Viewer

What this computes

Paste a values.yaml, add as many override files as you actually pass to helm install -f base.yaml -f override.yaml, and see the exact merged result — flattened into every leaf path, its final value, and which file it came from. This replicates Helm's real merge algorithm, not a naive object merge: verified against a real helm template run, not assumed from documentation.

What gets flagged

• Arrays are replaced, never merged. If two files both set the same array path, the later one fully replaces the earlier one — Helm never concatenates or merges array elements positionally, a common and reasonable assumption that's simply wrong.
• null deletes a key. Setting a key to null in an override doesn't clear its value — it removes the key entirely, reverting to nothing at all (not to a null value, and not to an earlier file's value for that key either).
• Unquoted yes/no/on/off become booleans. Helm's YAML parser follows YAML 1.1 rules — a value written as a bare word matching one of these is read as true/false, not the literal text, even when that text was clearly meant to be a string (country: NO, Norway's ISO code, becomes false).
• Unquoted numbers can lose their exact text. An image tag like 1.20 left unquoted parses as the number 1.2, silently dropping the trailing zero. A leading-zero number like 0644 is read as octal and becomes 420 — a real risk for anything written in Unix permission notation.

What this isn't

This merges values files exactly the way Helm does — it doesn't render chart templates, doesn't know a chart's own default values.yaml unless you paste it as the base file, and doesn't validate values against a chart's values.schema.json. For validating a rendered Kubernetes manifest itself, see Kubernetes YAML Validator.

FAQ

What order should I paste my files in?

Same order as your -f flags on the command line — the base chart values.yaml first, each override after it in the order it's applied. Later files win, exactly like Helm's own -f flag order. One exception, verified directly (this tool doesn't model it): --set always outranks every -f file, no matter where --set falls on the command line — --set image.tag=x -f override.yaml and -f override.yaml --set image.tag=x resolve identically, with --set winning both times.

Why does Docker Compose not have this same yes/no problem?

Different tools, different YAML parsers, verified separately rather than assumed to match: Helm's uses YAML 1.1 boolean rules, current Docker Compose's doesn't. Never assume one YAML-consuming tool's quirks apply to another without checking.

How is this different from Helm Values Diff?

This shows one configuration's full computed result. To compare two — say, what actually differs between a staging and production deployment — see Helm Values Diff.

Is my values data uploaded anywhere?

No — parsing and merging happen entirely in your browser.

Want the full write-up, not just the checks?

See Helm Values Explained for all of the above plus the difference between helm show values and helm get values for reading back what's actually deployed.