Why LDAP filters put the operator inside the parentheses

LDAP search filter syntax (RFC 4515) reads differently from most query languages people are used to — the combinator comes first, as a prefix, rather than sitting between two conditions: `(&(cn=John)(sn=Smith))` means "AND these," with the `&` leading the group rather than appearing between the two clauses the way `cn=John AND sn=Smith` would in SQL. This prefix notation makes deeply nested filters — combining AND, OR, and NOT freely — unambiguous to parse without needing operator precedence rules, at the cost of being genuinely harder for a person to read and hand-write correctly, especially once a filter nests three or four levels deep. That difficulty is exactly why building a filter from a row-based UI rather than typing the parenthesized syntax directly avoids a whole class of unbalanced-parens and misplaced-operator mistakes.

Why every value gets escaped automatically

Four characters have special meaning in LDAP filter syntax — backslash, asterisk, and the two parentheses — and RFC 4515 defines a specific backslash-hex escape for each. If a value you're searching for happens to contain one of these characters unescaped (a common case: an asterisk in a wildcard-like string, or a parenthesis in a display name), it would be interpreted as filter syntax rather than literal data, potentially changing what the filter actually matches or breaking it outright — the LDAP equivalent of a SQL injection risk. This tool escapes every value automatically for exactly that reason, so pasting arbitrary user-supplied text into a value field can't accidentally (or maliciously) alter the filter's structure.