# Kubectl get commands to accept labels as they're picked from kubectl get

**URL:** <https://discuss.kubernetes.io/t/kubectl-get-commands-to-accept-labels-as-theyre-picked-from-kubectl-get/35183>\
**Category:** General Discussions\
**Created:** [September 7, 2026, 10:22am UTC](https://discuss.kubernetes.io/t/kubectl-get-commands-to-accept-labels-as-theyre-picked-from-kubectl-get/35183 "2026-09-07T10:22:02Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![adolsalamanca](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/adolsalamanca/32/18477_2.png) [@adolsalamanca](https://discuss.kubernetes.io/u/adolsalamanca)\
**Post date:** [September 7, 2026, 10:22am UTC](https://discuss.kubernetes.io/t/kubectl-get-commands-to-accept-labels-as-theyre-picked-from-kubectl-get/35183/1 "2026-09-07T10:22:03Z")

</div>

Hello folks, nice to meet you all.

When I inspect resources with `kubectl get -o yaml`, labels are displayed as `key: value` (YAML mapping syntax). But when I filter with a selector, I have to switch to `kubectl get -l key=value`. Copying a label straight from the YAML output into a `-l` flag doesn’t work because of the different separator.

I understand the selector grammar (`=`, `==`, `!=`, `in`, `notin`) is an API-level spec, and that the colon is just YAML serialization. Still, since colons aren’t valid characters in label keys or values, accepting `key:value` in kubectl as sugar for `key=value` would be unambiguous.

Has this ever been discussed? I searched the kubernetes and kubectl repos and couldn’t find any issue proposing it. Would a proposal to SIG CLI make sense, or is there a known reason this was ruled out?

Thanks!

Regards,

Adol

### Cluster information:

Kubernetes version: k8s v1.34  
Cloud being used: AWS, Azure, Gcloud  
Installation method: kOps/CAPI  
Host OS: Ubuntu 24