What is a CRC and how to choose its parameters

Short answer

A CRC, or cyclic redundancy check, produces a short value from a sequence of bits. It is used to detect certain accidental errors in frames, files or storage blocks. It does not encrypt data and does not show who created it.

Choosing “CRC-16” does not define a complete algorithm. Two 16-bit models can use distinct polynomial, initial value, reflection or final XOR and produce different results for the same bytes.

The entire model, not just the width

Before implementing or testing a CRC, gather this data:

You should also know which bytes the calculation covers and how the result is placed. in the message. These two aspects belong to the protocol, they are not resolved for saying the name of the CRC.

Why “CRC-16” is ambiguous

The ASCII string 123456789 is a common check vector. With two 16-bit models produces:

Both results are 16 bits and both are correct for your contract. If the documentation only says “CRC-16”, information is still missing.

You can compare these models with the calculator CRC, which shows every parameter of the active preset.

What does the polynomial do?

A CRC interprets the sequence as a binary polynomial and calculates a remainder in arithmetic modulo 2. Parameter poly describes the divisor. in the notation Usually the main term is omitted, because it is determined by the width.

For example, for 16 bits:

poly 0x1021 → x^16 + x^12 + x^5 + 1

Do not swap the normal representation with a reflected shape that appears in the code of another implementation. 0x8005 and 0xA001 can be related by bit orientation, but do not stick indistinctly in a field without knowing what convention it expects.

Start, reflection and end XOR

init fills the register before processing the first byte. Start at zero or all ones changes the result even when the polynomial matches.

refin defines the order in which the bits of each byte enter. refout describes the registry orientation before applying xorout. The reflection of bits is not the same as reversing the order of the resulting bytes.

xorout applies a mask at the end. Therefore compare only the loop internal of two implementations does not guarantee that they implement the same model.

CRC-32 and CRC-32C are different models

The name can also be confused in 32-bit:

CRC-32/ISO-HDLC sobre "123456789" = 0xCBF43926
CRC-32C sobre "123456789"         = 0xE3069283

CRC-32C uses the Castagnoli polynomial and is not an alias of CRC-32/ISO-HDLC. The RFC 9260 specifies CRC-32C for SCTP. RFC 1662 documents 16 and 32 bit FCS used in PPP.

Choose parameters from the correct authority

Follow this order:

1. Identifies the exact version of the protocol, format or device.
2. Look for its official specification or manufacturer’s data sheet.
3. Copy the canonical name and all parameters, not a shorthand tag.
4. Confirm which bytes come in and in what order.
5. Check the vector 123456789 if the specification provides it.
6. Verify at least one real plot published by that same authority.
7. Document the order of transmission of the result.

A calculator is used to reproduce a known contract. cannot deduct reliably which model meant incomplete documentation.

Example: CRC-16/MODBUS and byte order

The hexadecimal bytes 02 07 produce the numeric value 0x1241 with CRC-16/MODBUS. However, Modbus RTU transmits the least byte first. significant:

CRC value:          0x1241
Orden visual MSB:   12 41
Orden Modbus LSB:   41 12

Reversing bytes does not change the mathematical value, but it does change how it is serialized in the plot. The Modbus Serial specification Line defines both the calculation like this transmission order.

Text and bytes are not the same

The CRC always processes bytes. If you type 02 07 in text mode, you will calculate the characters 0, 2, space, 0, 7; not the 0x02 and 0x07 bytes.

For text you must also agree on the encoding. The letter é in UTF-8 can be represented as C3 A9, while a visually equivalent sequence you can use 65 CC 81. If the bytes differ, the CRC must differ.

Before comparing results record:

• the exact hexadecimal sequence;
• coding and normalization, if the source is text;
• whether headers, lengths, addresses or the CRC field itself are included;
• multibyte byte order.

What errors can you detect

The detection capacity depends on the polynomial, the length of the messages and the error pattern. A well-chosen CRC can detect all errors certain types up to defined limits, but there is no generic guarantee that applies equally to any polynomial and length.

That is why it is not advisable to invent parameters just because they produce a value of 16 or 32 bits. Use the model studied and required by the system with which you must interoperate.

A CRC does not provide cryptographic security

There is no secret key. Whoever modifies a message can calculate the CRC new, so the receiver cannot distinguish a deliberate alteration from a legitimate message. A CRC neither hides data nor proves the identity of the sender.

For integrity against an attacker an authenticated mechanism is needed, such as a MAC or a signature within an appropriate protocol. A hash SHA-256 is useful for identifying content, but by itself it also does not authenticate the sender.

Interoperability checklist

• Width, polynomial, init, refin, refout and xorout match.
• The polynomial form uses the convention expected by the implementation.
• Vector 123456789 produces the correct check value.
• Both sides process exactly the same bytes.
• Text encoding is fixed.
• The result occupies the correct number of bits and leading zeros.
• The order of CRC transmission is documented.
• CRC is used for accidental errors, not for authentication.

The Tools in a Tab calculator processes UTF-8 text or hexadecimal bytes locally. Includes custom presets and parameters from 8 to 64 bits, but the Final selection should always come from the specification that governs your system.