See which pods your selector matches — and why.

Because that is what the rule says, and it is the single most surprising line in the whole label-selector API. In k8s.io/apimachinery, Requirement.Matches handles NotIn and != with one branch: if the label set does not have the key, return true. In and == take the opposite branch: if the label set does not have the key, return false. So env!=prod means "no env label saying prod", which a pod with no env label satisfies perfectly. If you meant "has an env label, and it is not prod", you need two clauses: env,env!=prod — Exists AND NotIn. This tester annotates every clause that holds because the key is absent, so you never have to remember which way round it goes.

matchLabels is a plain map, and every pair in it becomes one equality requirement: {app: web, tier: frontend} is exactly app=web,tier=frontend. matchExpressions is a list of {key, operator, values} entries and is the only way to write the set-based operators In, NotIn, Exists and DoesNotExist. When a selector has both, apimachinery ANDs everything together — LabelSelectorAsSelector adds each matchLabels pair and each expression to the same requirement list. There is no OR anywhere in a label selector, at any level.

No, and this is the mistake generated manifests make most often. A Service's spec.selector is typed map[string]string, not a LabelSelector: it takes a plain label map and supports equality only. Write matchLabels or matchExpressions there and the API server rejects the field outright. Deployments, StatefulSets, DaemonSets, Jobs and NetworkPolicy podSelector all take a real LabelSelector and accept both forms. Paste a Service manifest with matchExpressions into this tester and it warns you, then shows what a Deployment WOULD have matched — so you can see both the error and the intent.

It depends on whether the field is empty or absent, and the two are not the same. An empty LabelSelector — {}, or matchLabels: {} — is labels.Everything(): it matches every object, which is exactly why a NetworkPolicy with podSelector: {} applies to every pod in the namespace. A selector that is nil, on the other hand, matches nothing: LabelSelectorAsSelector(nil) returns labels.Nothing(). And a Service is a third case again: its selector field is omitted when empty, so a Service with selector: {} is a Service with no selector, and the endpoints controller does not manage its endpoints at all.

No. Both parsers, the validator and the matcher are JavaScript running in your tab — there is no server, no API call and no logging, so 0 bytes are uploaded. That matters here because a pod dump is not neutral text: it carries internal image references, node names, annotations, sometimes a token mounted as an env var. This is the tool you can use on production output without a conversation about data handling.

The pod labels, not the Service. Paste the Service manifest as the selector and the actual pods as the resources: the tester reads spec.selector for you and shows a per-clause trace on each pod, so a one-character label typo shows up as label tier="frontnd" ≠ "frontend" instead of as an empty endpoint list. Two structural traps to rule out as well. First, a Service selects POD labels, not the Deployment's own metadata.labels — this tester lists a workload's spec.template.metadata.labels as its own "Pod template" row for exactly that reason. Second, a selector that matches nothing is never an error anywhere in Kubernetes: kubectl accepts it, the API accepts it, and the only symptom is an empty endpoints object.

No, and that is a deliberate fence rather than a missing feature. Field selectors are a different mechanism: they filter on an object's own fields, they are evaluated by the API server against a small allow-list that varies per resource type, and almost none of them support set-based operators. Simulating them offline would mean encoding which fields each Kubernetes version indexes for each kind, and getting it subtly wrong. This tool covers label selectors, which are uniform across every resource type and fully defined by the object you already have in your clipboard.

They exist, but not on a label selector. Node affinity uses NodeSelectorRequirement, a separate type whose operator set is In, NotIn, Exists, DoesNotExist, Gt and Lt. A LabelSelectorRequirement — the one inside matchExpressions, spec.selector and podSelector — has only the first four. So Gt and Lt are valid in nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution and invalid everywhere this tester looks. Type replicas>2 into the selector field and it says so rather than inventing a comparison a label selector does not have.

It evaluates the first 500 resource documents from a paste of up to 500,000 characters, and a selector of at most 100 clauses — every cap says so on screen with the real count, so a truncated run never looks like a complete one. Keys and values are validated against the real limits: a label key name is at most 63 characters, an optional DNS-subdomain prefix before the / at most 253, and a label value at most 63 (an empty value is legal). An invalid key or value in the SELECTOR is a hard error, because the API server would reject it; an invalid label on a RESOURCE is only a note, because the question you asked was whether the selector matches it.