Equal to (=)

What it does

value1 = value2

A = B returns the logical TRUE or FALSE according to whether the two operands are equal under Excel's comparison rules — which are not the rules of IEEE-754, not the rules of ordinary string equality, and not the rules of a type-strict language.

Three rules do all the work. They are shared by all six comparison operators, and this page is where they are stated in full.

Rule 1 — cross-type ordering, not cross-type coercion

   any Number   <   any Text   <   any Logical

So the number 10 is less than the text "2", and FALSE is greater than any number. Under this rule A = B between operands of different kinds is always FALSE, no matter how convertible they look. This is the single most important thing on the page: 1 = "1" is false, and every "why doesn't my lookup match?" question in a spreadsheet forum eventually arrives here.

Note the contrast with arithmetic: + does coerce "1" to 1. Comparison and arithmetic have opposite doctrines about text, in the same formula language.

Rule 2 — text comparison is case-insensitive

The contract records comparison text lanes as case-insensitive on the admitted slice, with ="a"="A" yielding TRUE. = is therefore not string identity. EXACT is the case-sensitive alternative.

Beyond case, text comparison raises collation questions — accents, ligatures, non-Latin scripts, locale-specific ordering — which the contract explicitly puts out of slice ("locale and collation-sensitive text ordering beyond the current installed baseline"). Apart from the Hangul jamo pairs in FN-OP_EQUAL-001, nothing about non-ASCII text ordering is settled here.

Rule 3 — numeric equality is normalized, not exact

The rule that surprises engineers most. The contract records that numeric-vs-numeric comparisons on the admitted operator slice do not use exact IEEE-double equality, but a currently pinned normalization lane, with the current local model described as "truncation-style normalization to 15 significant decimal digits on the tested compare paths, not round-to-nearest". Its baseline finding is the classic one: =0.1+0.2=0.3 yields TRUE, together with the matching results for the other five comparisons.

This is why a spreadsheet appears not to suffer from floating-point equality problems while the arithmetic underneath it plainly does. The comparison layer hides the residue that the arithmetic layer creates.

Two consequences worth spelling out:

• Equality here is not the same relation as bitwise equality. Two distinct doubles can compare equal. Any implementation that reaches for a == b on doubles has implemented a different function.
• Whether the relation is transitive depends on which model is right. A normalization model (round or truncate each operand to 15 significant digits, then compare exactly) is transitive: it is equality of a function of the operands. A tolerance model (compare the difference against a scaled epsilon) is not transitive: a≈b and b≈c need not give a≈c. The contract names the normalization model as its current local one and marks the whole lane as currently pinned rather than settled — so transitivity of = on numbers is an open question with a decisive experiment behind it.

The other =

The = a reader types first is not this function. A leading = introduces a formula: it is grammar, telling the host that what follows is an expression rather than literal content. This operator is the = that appears inside an expression, between two subexpressions. =A1=B1 contains both: the first = is the formula marker, the second is FUNC.OP_EQUAL. Chapter 03 draws exactly this line — parse-only syntax carries no semantics and gets no function identity, while every evaluable operator does.

Arguments

Arity is exactly 2; no optional arguments, no defaults. Equality is symmetric, so operand order does not change the value — but it does set the broadcast orientation when the operands are arrays of different shapes.

Try it

Quirks

Result and edge cases

• Blank operands. The contract records blank comparison as context-sensitive, with the blank taking the shape of the other operand: blank vs number behaves as 0, blank vs text as "", blank vs logical as FALSE. Its baseline findings include a blank cell comparing equal to 0 and a blank cell comparing equal to "" — which together mean =A1=0 and =A1="" can both be TRUE for the same empty A1, even though 0 and "" are not equal to each other. This is not a contradiction; it is what context-sensitive blank coercion means, and it is a genuine trap.
• Empty text versus blank. "" is a text value of length zero; a blank cell is the Empty kind (chapter 01). They are different values that can compare equal to the same things.
• Arrays. The contract records the ordinary broadcast rule: singleton dimensions broadcast, row-vs-column combinations produce two-dimensional grids, and coordinates neither operand can supply return #N/A. Its findings include ={1,2}={1;2} producing a 2×2 grid of logicals.

Errors

How to implement

Notes for implementers

• Do not implement = as a == b on doubles, and do not implement it as a type-coercing comparison. Both are different functions from the one described here.
• Implement the kind ordering as an explicit total order over kinds, then compare within kind. That structure makes rules 1 and 2 separable and testable.
• Put the numeric normalization in one place shared by all six comparisons. If = and < normalize differently, the operators stop being consistent with each other — and a reader can detect that with three cells.
• Case-insensitive comparison is not to_lowercase in general. For ASCII it is; for Unicode, case folding has locale-sensitive edges (Turkish dotless i is the standard example), and the contract puts that surface out of slice — so a compatibility implementation should record what it does rather than assume.
• Comparison is SafePure, Deterministic, NonVolatile.

Rust code

CatalogueEntry::operator(EQUAL, "=", Notation::Infix, VALUES, equal)

fn equal(
    arguments: &[CalcValue],
    services: &mut EvalServices<'_>,
) -> Result<CalcValue, FunctionFault> {
    compare(EQUAL, arguments, services, Want::Equality, Ordering::is_eq)
}

No implementation has been published with a Handbook test suite for this function.

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• FUNC.OP_NOT_EQUAL — the complement, with the error caveat noted on that page.
• FUNC.OP_LESS_THAN, FUNC.OP_LESS_EQUAL, FUNC.OP_GREATER_THAN, FUNC.OP_GREATER_EQUAL — the ordering siblings; same three rules.
• EXACT — case-sensitive text equality. Where = says "a"="A" is true, EXACT says it is false. If case matters, = is the wrong operator.
• IF, COUNTIF, SUMIF, SUMIFS, MATCH, XLOOKUP — the consumers. Note that the criteria strings of the *IF* family ("=5", ">3", "<>") are a separate mini-language parsed by those functions; they are not this operator, and their matching rules — wildcards, in particular — do not follow the rules on this page.
• DELTA — the engineering-function equivalent for numbers, returning 1 or 0.

Named variants

No named variants are recorded yet.