Kubeconfig Viewer & Merger

How it works

Merging parses each pasted kubeconfig with js-yaml, then walks the clusters, contexts, and users arrays of every file in the order they're listed, adding each entry to the merged result only if its name hasn't already been claimed by an earlier file — mirroring kubectl's actual KUBECONFIG environment-variable merge rule, where the first file to define a given name wins and every later duplicate is silently dropped rather than merged field-by-field.

FAQ

If two files define a cluster with the same name, does it merge their fields together?

No — kubectl's merge rule (and this tool's) is winner-take-all per name, not a field-level merge. Whichever file listed that name first is kept in its entirety; the later file's entry for that name is discarded completely, even if it has fields the first one doesn't.

Which current-context ends up in the merged output?

The first non-empty current-context found across the files, in the order you pasted them — matching how kubectl resolves it when merging multiple KUBECONFIG paths.