How this instrument works
Parity checking protects a block of data with one extra 'parity bit', chosen so that the total count of 1-bits, data plus that extra bit, always follows a fixed rule known in advance by both sender and receiver. Odd parity fixes that rule at odd: the total number of 1-bits must always come out odd. If a receiver recounts the 1s and lands on an even total, it knows at least one bit was corrupted in transit.
The odd-parity bit is the mirror image of the even-parity bit for the same data, and getting the direction right matters: count the 1-bits in the data. If that count is already odd, this bit is 0 — no change needed, the total stays odd. If the count is even, this bit is 1 — adding one more 1 pushes the even total up to odd. This is the opposite assignment from the even-parity rule, which sets the bit to keep the total even rather than odd.
Odd parity is used in exactly the same class of systems as even parity — legacy serial links, some memory-error-detection hardware, and low-level communication protocols — with the specific convention (odd vs even) chosen once at the protocol or hardware-configuration level and then applied consistently. Some hardware, notably certain RS-232 serial port configurations, defaults to this convention specifically because it can also catch a stuck-at-zero fault (a line frozen at all zeros) that its even counterpart, with its own all-zero-is-valid case, would miss.
This instrument works with an 8-bit data word, matching the byte-oriented framing most commonly used for teaching this concept and for real serial-port settings. Toggle any bit and the output recomputes immediately, making the odd-vs-even distinction concrete rather than something to memorize as an abstract rule.
- Toggle Bit 1 through Bit 8 to 0 or 1 to represent the data byte you want to protect.
- Read Number of 1-bits in the data to see how many bits are currently set high.
- Read Odd parity bit — this is the bit you'd append so the total 1-count, including this bit, is always odd.
- If you're checking a received byte plus its parity bit under an odd-parity protocol, enter the received data bits here and compare against the parity bit that arrived — a mismatch means a bit flipped somewhere.
- Compare the same data byte against this site's even-parity instrument to see the two conventions diverge — for almost every input they produce opposite parity bits.
Worked example — data byte 1,1,0,1,0,0,0,0, checked against odd parity
Set bit1=1, bit2=1, bit3=0, bit4=1, bit5=0, bit6=0, bit7=0, bit8=0 — the same eight-bit data byte used to demonstrate even parity elsewhere on this site. Number of 1-bits in the data reads 3, an odd count already. Odd parity bit reads 0, because the count is already odd — adding a 1 would wrongly push the total to 4 (even), so the correct value here is 0, not 1.
That 0 is the opposite of the even-parity bit (1) computed for this exact same data, which is the point: for data with an odd count of 1s, the even-parity version needs a 1 to reach an even total while this one needs a 0 to stay odd. Data plus this bit together (1,1,0,1,0,0,0,0,0) still contains 3 ones — odd, exactly as the rule requires.
Questions
What is odd parity used for?
Odd parity is an error-detection scheme where one extra bit is added to a data block so the total number of 1-bits, data plus that bit, is always odd. A receiver recounts the 1s across the received bits; if the total comes out even, at least one bit was corrupted in transit. It's used in the same class of legacy serial and memory-error-detection hardware as even parity — some RS-232 configurations default to it specifically because it also flags a line stuck at all-zeros, a fault its even counterpart's own all-zero-is-valid case would miss.
How do you calculate the odd parity bit?
Count the number of 1-bits in the data. If that count is already odd, this bit is 0 (no change needed to stay odd). If the count is even, this bit is 1 (pushing the even total up by one to become odd). For example, data 1,1,0,1,0,0,0,0 has three 1-bits, already odd, so the correct bit is 0 — appending a 1 instead would incorrectly make the total even.
What's the difference between odd parity and even parity?
Both schemes add one bit to make a data block self-checking, but they target opposite totals: even parity sets its bit so the total 1-count is always even, while odd parity sets its own bit so that total is always odd. For the same data bits, the two schemes produce the same result only when the assignment happens to coincide by the specific count of ones — in general they're opposite, which is why a system must be configured to use one convention consistently, since mixing them makes every check fail.
Why would a system choose odd parity over even parity?
The two schemes detect single-bit errors equally well — neither is mathematically 'better' at that job. The practical reason to prefer it historically was hardware-specific: it guarantees at least one bit in every transmitted frame (data plus the extra bit) is a 1, so a communication line stuck permanently at logic 0 — a common hardware fault — is caught immediately, since a valid frame under this rule can never be all zeros. The even-parity version's all-zero data byte, by contrast, legitimately produces an all-zero result too, so a stuck-at-zero line wouldn't stand out as obviously wrong.
Why does an all-zero byte need an odd parity bit of 1?
An all-zero byte has zero 1-bits, and zero is even, so to reach an odd total under this rule, this bit must add exactly one 1 — making it 1 and the total count of 1s (across data plus that bit) equal to 1, which is odd. This is the opposite of the even-parity treatment of the same all-zero byte, where that bit stays 0 because zero is already even.