XNOR Gate: The Equality Detector That Powers Error Detection

In the previous post, we built XOR from relays — the gate that asks are these two inputs different? It lit a lamp precisely when its inputs disagreed. That circuit is powerful, but there is an equally important question hiding right behind it.

Not “are they different?” — but “are they the same?”

That question is the XNOR gate. Flip XOR’s output and you get the atom of comparison: the primitive that underlies every equality test, every conditional branch, and the entire field of error detection. It is also, as we will see, the question that a frustrated engineer at Bell Labs in 1947 was driven to answer once and for all.

From XOR to XNOR: one inversion, a new question

The XNOR gate’s name says it directly: Exclusive-NOR, or NOT(XOR). Every XNOR gate is, at its logical core, an XOR followed by an inversion through a normally-closed relay contact.

In Boolean notation, XOR is written $A \oplus B$. Adding NOT gives:

The symbol $\odot$ — a circled dot — is the XNOR operator. Read it as “A equals B,” because that is precisely what it tests.

There is something satisfying about deriving XNOR this way. You already know XOR. You already know NOT from Post 6. XNOR is their composition: familiar parts, a new arrangement, one extra relay contact making all the difference.

The truth table: when matching is everything

Step through the four possible input combinations and watch what changes:

The pattern is the mirror image of XOR. The two rows that produce a lit lamp — both 0, and both 1 — are the rows where A and B agree. The two dark rows are the mismatches. XNOR lights up for equality and goes dark for difference.

Think of it physically. Both switches open: no signal on either line, the circuit confirms agreement and lights up. Both switches closed: both lines are active, the circuit confirms agreement again. One open and one closed: a mismatch, the lamp stays dark — a silent signal that these two bits are not saying the same thing.

The ability to distinguish “same” from “different” sounds simple. What makes it profound is how often a computer needs to do it, and what happens when bits change without permission.

Richard Hamming and the weekend that changed computing

The year is 1947. Richard Hamming is a mathematician at Bell Labs in Murray Hill, New Jersey. He submits jobs for the weekend batch run on the relay computers. On Monday morning he arrives to find that a relay had misfired during the night, silently flipping a single bit — and the machine’s error-detection circuitry had halted the entire job without fixing anything. The calculation has to start over, again.

Hamming is furious. “If the machine can detect an error,” he later wrote, “why can’t it locate the position of the error and correct it?”

He spent the next several years working on the answer. In 1950, he published the result in the Bell System Technical Journal: Hamming codes, the first practical error-correcting codes in the history of computing.

The key insight is built entirely on XOR and XNOR. The simplest version is parity. Before sending four data bits, you count how many 1s are present and append a parity bit that makes the total count even. The receiver XORs all received bits: if the result is 0, parity is intact and no single-bit error occurred; if it is 1, a bit flipped. XNOR’s equality check — does the computed parity match what was expected? — is the verification step.

Hamming extended parity into something more powerful. By adding multiple parity bits, each covering a different subset of the data bits, the pattern of failed checks forms a binary number pointing directly to the position of the flipped bit. The machine doesn’t just know something went wrong — it knows exactly which bit to flip back. Error detected, located, corrected, automatically.

Hamming codes became the foundation of all modern error-correcting codes: Reed-Solomon codes (CDs, DVDs, QR codes, deep-space telemetry), the codes used in Wi-Fi and 5G, the codes protecting your hard drive against bad sectors. Every one of them descends from the insight that XOR can generate a “signature” of a data word and XNOR can verify whether that signature survived transmission. The next time you scan a torn QR code and it reads perfectly, something descended from Hamming’s frustrated weekend math is working quietly in the background — asking, for every bit, the same question our relay circuit just answered: are these two bits the same?

Try it yourself

Below is a live XNOR gate in the DigiSim simulator — a real relay simulation, not an animation. Two inputs, one output lamp, the contacts wired for equality detection.

Three things to try:

1. Predict before you toggle. With both switches open (A=0, B=0), what does the truth table say the lamp should do? Confirm it. Then close both (A=1, B=1). Two different matching states, same lit output — that is XNOR’s defining pattern.

2. Set up a mismatch and resolve it. Close switch A but leave B open (A=1, B=0). Lamp dark — mismatch detected. Now close B too (A=1, B=1): the lamp returns. You have just watched a comparator cross from inequality to equality. Listen to the clicks as you do it; each one is a bit of state changing.

3. Compare to Post 10’s XOR circuit. Give both circuits identical inputs simultaneously. Their outputs are always opposite: when XOR is lit, XNOR is dark, and vice versa. XOR detects difference; XNOR detects equality. Complement pairs, covering both answers to the same question.

Where equality detection lives

Comparators — the circuits that decide whether two numbers are equal — are chains of XNOR gates, one per bit. An 8-bit comparator runs eight XNOR gates in parallel. If every pair of corresponding bits matches, every XNOR outputs 1, and an AND gate collecting all eight outputs confirms equality. One mismatched bit — one XNOR outputting 0 — collapses the AND tree and flags inequality. This structure sits inside every processor, memory controller, and address decoder.

Conditional branches — the if A == B then... in every program — ultimately reduce to exactly this bit-by-bit equality check in hardware.

Parity verification — the XOR/XNOR check described above — runs in the background of every storage device and network connection, silently guarding every bit you have ever trusted to a machine.

XNOR and XOR are complement pairs, like AND and NAND, or OR and NOR. In relay hardware, the difference between the two is exactly one contact choice: normally-open for XOR, normally-closed for XNOR. The same lesson NOT taught in Post 6 — that a single contact wiring decision inverts a gate’s entire meaning — echoes through every gate in this series.

What you just learned — and what’s next

In this post:

• XNOR = NOT(XOR): invert XOR’s output and you get the equality detector — 1 when inputs match, 0 when they differ.
• The truth table is the exact complement of XOR’s: the two “matching” rows light up, the two “mismatched” rows go dark.
• Richard Hamming’s frustration at Bell Labs led to Hamming codes (1950) — the first error-correcting codes, built entirely on parity (XOR/XNOR) mathematics and still the foundation of every error-correction scheme in computing.
• XNOR is the foundation of comparators, conditional equality tests, and parity verification — three operations woven through everything a computer does.

The series has now covered all the fundamental two-input gates: AND, OR, NOT, NAND, NOR, XOR, XNOR. Each one is a different question about its inputs. The next circuit goes a step further: instead of asking about its inputs, it chooses between them.

In Post 12, we will build the multiplexer — a circuit that routes one of several inputs to a single output, under the control of a selector signal. A multiplexer is the first circuit in this series that feels like it has a decision baked in: given a choice, take this road rather than that one. It is the gateway to every data bus, address decoder, and conditional route that a computer uses to move information. The click of a relay choosing a path is very close.

Every circuit in this series lives in the DigiSim Relay Lab.