CRC-16 XMODEM checksum
The nine characters 123456789 give the CRC-16/XMODEM value 31c3, or 12739 in decimal, the documented check result for the zero-start CCITT profile used in classic file transfer and firmware. Paste any text to get its checksum. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- 123456789
- Result
- 31c3
- Crc16
- 31c3
- Hex
- 31c3
- Decimal
- 12,739
CRC-16/XMODEM is a sixteen-bit cyclic redundancy check used in classic file-transfer framing, embedded firmware, and protocol stacks that need a compact integrity word rather than a full cryptographic hash. Engineers, students, and support teams often need the same textbook result for a short string: the CCITT generator polynomial 0x1021, initial register zero (the XMODEM seed), no bit reflection, and zero final XOR—exactly the CRC-16/XMODEM profile whose check value for the ASCII digits one through nine is hexadecimal 31C3. This CRC-16 XMODEM checksum tool accepts non-empty text, encodes it as UTF-8, runs that deterministic shift-and-XOR loop, and returns the sixteen-bit checksum as four lowercase hexadecimal digits together with the decimal value and a short summary.
What CRC-16/XMODEM with polynomial 0x1021 computes and why the hex word matters
A cyclic redundancy check treats a message as a polynomial over the Galois field of two elements and divides it by a fixed generator polynomial, leaving a remainder that becomes the checksum. For CRC-16 the remainder is sixteen bits wide, so the entire result fits in one word and is naturally written as four hexadecimal digits. The generator used by XMODEM and many CCITT-style examples is 0x1021, which expands to x to the sixteenth plus x to the twelfth plus x to the fifth plus one.
In software the division is performed by exclusive-oring each input byte into the high eight bits of a sixteen-bit register and shifting left eight times, exclusive-oring the generator whenever the high bit is set. This landing always uses that non-reflected algorithm with initial value zero and final XOR zero, which is the profile whose documented check value for the nine-byte ASCII string one two three four five six seven eight nine is 31C3.
The response also echoes the decimal integer, the polynomial string 0x1021, the algorithm label CRC-16/XMODEM, the UTF-8 byte count, and the original text so clients can display a full audit line without re-deriving metadata. Because CRC-16 is not collision-resistant and not keyed, treat it as a framing or accidental-corruption check, not as proof of authenticity; prefer SHA-family digests when the search intent is cryptographic hashing rather than a two-byte CRC.
Where a CRC-16 XMODEM checksum is useful
Firmware authors and serial-protocol students use a CRC-16 XMODEM checksum calculator to verify hand-computed remainders against the zero-seed CCITT polynomial without writing a shift loop in every language. Teaching platforms and LMS plugins need a deterministic oracle that rejects empty input instead of returning zero for the empty message, so auto-graders can distinguish missing answers from a real checksum of zero.
Content sites ranking for CRC-16 XMODEM, CRC16 XMODEM calculator, or CCITT poly 0x1021 checksum benefit from a live tool whose free path matches the paid automation path byte-for-byte on the same pure module. Validation failures never consume balance after rejection.
Pair with CRC-8, CRC-32, or cryptographic hash landings only when the search intent moves beyond a sixteen-bit XMODEM framing check—keep this page focused on zero-seed poly 0x1021 CRC-16/XMODEM so SEO intent stays sharp and does not collide with MODBUS, IBM, or CCITT-FALSE variants that share a family name but not the same check vector.
What you can do with it
Classroom CRC remainder demos
Teachers show the classic 123456789 → 31C3 check value and let students recompute other short strings without installing a CRC library.
FAQ
Which CRC-16 parameters does this tool use?
CRC-16/XMODEM: poly 0x1021 (CCITT), init 0x0000, no reflection, xorout 0x0000. The documented check for ASCII 123456789 is 31C3.
What happens if the text is empty?
A non-empty string is required; empty input is not treated as a successful zero checksum.
Is the CRC-16 XMODEM checksum calculator free?
The browser tool runs free on your device.
Is CRC-16/XMODEM the same as CRC-16/CCITT-FALSE?
No. Both use poly 0x1021, but XMODEM seeds the register with zero while CCITT-FALSE uses 0xFFFF, so check values differ. This tool implements XMODEM only.
How are accented letters and other non-ASCII characters counted?
Text is encoded as UTF-8 before the calculation, so a character that takes several bytes adds every one of them, exactly as an embedded device would see it if it received the same UTF-8 stream.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/crc16-xmodem \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"123456789"}'const res = await fetch("https://api.kit.forhosting.com/enc/crc16-xmodem", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "123456789"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/crc16-xmodem",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "123456789"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/crc16-xmodem", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"123456789"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"123456789"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/crc16-xmodem", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "123456789"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.crc16_xmodem",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Empty input is rejected with invalid_input so callers never confuse a missing field with a real zero checksum.
What CRC-16/XMODEM with polynomial 0x1021 computes and why the hex word matters
Critically, the XMODEM profile seeds the register with zero rather than all-ones; that single choice separates CRC-16/XMODEM from CRC-16/CCITT-FALSE, which uses the same poly but init 0xFFFF and therefore different check values for the same payload.
Input contract, empty-string errors, and the JSON response shape
The string is encoded as UTF-8 before the CRC loop, so multi-byte characters contribute every code unit byte exactly as an embedded device would if it received the same UTF-8 stream. Pin both a success path and an empty-input error in continuous integration so accidental poly or init changes cannot ship unnoticed. Optional null fields are omitted rather than emitted as null, matching the declarative renderer contract for clean web forms. POST a JSON body with a single required string field named text: any non-empty sequence of characters you want to checksum. Aliases input, value, s, data, message, and payload are accepted for the same field so SDK stubs and form posts stay flexible. Missing text, a non-string value, or an empty string all fail with invalid_input and a clear message that a non-empty string is required; those failures are not billed on the prepaid API. On success the body includes result, crc16, and hex all set to the same four-digit lowercase hexadecimal checksum; decimal set to the integer zero through sixty-five thousand five hundred thirty-five; polynomial fixed at 0x1021; algorithm fixed at CRC-16/XMODEM; input_bytes equal to the UTF-8 length; text echoing the input; and message summarizing the byte count and hex result. Keep payloads to ordinary text sizes appropriate for a Worker isolate item call; this tool is for short strings and protocol snippets, not multi-megabyte binary blobs.
Where a CRC-16 XMODEM checksum API earns its keep and how pricing works
Call the free in-browser tool for one-off checks; call the prepaid KIT API from backends, serverless functions, and SDKs when you need a stable contract under balance at $0.002 per successful item.
Integration use cases
XMODEM and serial protocol checks
Verify that a payload string produces the expected sixteen-bit CRC-16/XMODEM trailer under poly 0x1021 and init zero before comparing device logs or unit-test vectors.
CI fixtures for framing code
Pipelines pin deterministic CRC-16/XMODEM hex outputs and the empty-input error so accidental poly or init changes fail fast.
Technical questions
How do I compute a CRC-16 XMODEM checksum of text?
Send JSON with a non-empty string field text. The API UTF-8-encodes the string, runs CRC-16/XMODEM with polynomial 0x1021 and init 0x0000, and returns the word as four lowercase hex digits in result, crc16, and hex.