We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Online CRC16 checksum tool to calculate 16-bit cyclic redundancy check values for text, Hex, and Base64 data to verify data integrity.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
“CRC16” names a result width, not one universal calculation. This calculator uses the CRC-16/XMODEM parameter set: width 16, polynomial 0x1021, initial value 0x0000, no input or output reflection, and final XOR 0x0000. It returns one four-character hexadecimal result in uppercase. A matching polynomial alone is not enough to identify a CRC variant; initialization, bit direction, and final XOR also matter.
The input is a text string. For an ASCII check string, each character has the expected single-byte value. The calculator does not provide separate file, raw-byte, hexadecimal-input, or Base64-input modes. If a protocol specifies a byte encoding such as UTF-8, calculate over those encoded bytes with a matching implementation before comparing results.
CRC-16/XMODEM parameters: width=16; poly=0x1021; init=0x0000; refin=false; refout=false; xorout=0x0000
Enter the ASCII text 123456789; the expected check value is 31C3. The page updates the checksum as the text changes and displays a copy control. As a second reproducible example, Hello World produces 992A. Spaces, letter case, punctuation, and line breaks are part of the input, so changing even one character changes the data being checked.
NIST describes CRC as a non-cryptographic checksum for detecting expected accidental changes. Compare values only when both sides use the same algorithm and the exact same input representation.
31C3 check value; checked 2026-09-28.Guide
Follow the workflow and verify inputs and outputs with practical examples.
Check the protocol or program documentation for CRC-16/XMODEM and its parameters. A label that says only “CRC16” is ambiguous.
Paste the characters you need to check. Do not remove spaces, change capitalization, or add a line break unless the original data contains that change. For a known test, enter 123456789.
The result appears in uppercase hexadecimal and can be copied. Compare it with a value calculated from the same characters using the same CRC variant.
If your input represents bytes rather than literal text, first make sure your other implementation uses the same encoding and byte order expected by the protocol. This page does not parse a written hex string into bytes.
Use cases
See how the tool fits into real work and everyday tasks.
When a protocol note supplies an ASCII sample and CRC-16/XMODEM parameters, enter the sample and compare the four-digit result before testing longer records.
If a device or program disagrees, test 123456789 first. A result other than 31C3 suggests checking the chosen CRC parameters or input encoding.
Record an exact text sample with its expected checksum for a test fixture. Preserve whitespace and line endings so the fixture represents the bytes or characters your system actually processes.
Q&A
Find concise answers to common questions and confusing cases.
No. CRC-16/XMODEM is one variant. Compare width, polynomial, initial value, reflection settings, final XOR, and input bytes with the target system.
No. The input is text and the tool has no raw byte, hex-decoding, Base64, or file mode. A string such as 313233 is treated as those characters, not bytes 0x31, 0x32, 0x33.
No. A CRC is not a cryptographic hash or authentication mechanism. It can help detect accidental changes, but a matching CRC does not establish who sent the data or protect it against deliberate modification.
Protocols operate on bytes with a specified encoding. This page accepts text, so non-ASCII characters may not correspond to the UTF-8 or other byte sequence used by your protocol. Convert and check the required bytes with an implementation that supports that input model.
Notes
Review scope, result limitations, and important precautions before use.
CRC is intended for error detection where accidental changes are expected. It is not encryption, a cryptographic hash, a digital signature, or proof of authenticity.
CRC values are only comparable when the exact input and full algorithm parameters agree. For real protocol work, confirm the protected byte range, character encoding, and the protocol's byte ordering rules. The displayed hexadecimal value is a checksum number; this page does not assemble a protocol frame or append checksum bytes.
Related
Discover related tools, collections, and available API capabilities.