CRC-16 Kermit checksum
The nine characters 123456789 give the CRC-16 Kermit value 2189, the reference result for this profile, so you can tell at once whether a device or library really uses Kermit. Paste any text to get its 16-bit residual. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- 123456789
- Crc hex
- 2189
- Crc int
- 8,585
- Byte count
- 9
- Algorithm
- CRC-16/KERMIT
CRC-16 Kermit is the sixteen-bit cyclic redundancy check defined by the Kermit file-transfer protocol and catalogued as CRC-16/KERMIT. It uses the reflected CCITT generator polynomial 0x1021 (implemented as 0x8408 in reflected form), starts the register at zero, reflects both input bytes and the final residual, and applies no final exclusive-or.
What CRC-16 Kermit actually computes
A cyclic redundancy check runs every byte of a message through a fixed generator polynomial, so that a single flipped bit almost always changes the result. CRC-16 Kermit is the sixteen-bit profile adopted by the Kermit file-transfer protocol and many serial tools. It belongs to the CCITT family, built on the polynomial 1021 in hexadecimal, but both the input bytes and the final value are reflected, the register starts at zero and no final mask is applied. Your text is first turned into UTF-8 bytes, so accented letters and emoji count as several bytes, and the result is shown as four hexadecimal digits and as a whole number.
How to check it and the mix-ups to avoid
The reference test is the nine characters 123456789, which must give 2189. If a library returns anything else, it is not CRC-16 Kermit, whatever its label says. The most common mix-up is with other sixteen-bit checks that share family names: CCITT-FALSE starts from FFFF without reflection, while XMODEM and Modbus use other settings, so the same text yields different values. An empty message is rejected rather than reported as zero. Finally, a CRC is a public, linear calculation: it detects accidental damage but offers no secrecy, so never use it as a password hash or a signature.
What CRC-16 Kermit is and when to use it
A cyclic redundancy check folds every input byte through a fixed generator polynomial so that a single flipped bit almost always changes the residual. CRC-16/KERMIT is the sixteen-bit profile that the Kermit protocol and many serial tools adopted from the CCITT family: the non-reflected generator is 0x1021, but because both input and output are reflected, practical bit-at-a-time code uses the reflected poly 0x8408, initializes the register to 0x0000, exclusive-ors each data byte into the low eight bits, then performs eight shift-and-conditional-xor steps per byte with no final exclusive-or mask.
The classic check vector is the nine ASCII digits one through nine, which must yield residual 0x2189; if your library disagrees with that value, it is not CRC-16/KERMIT even if it advertises CCITT. Do not use it as a password hash or keyed MAC: cyclic redundancy checks are public linear functions and offer no secrecy against a motivated attacker.
FAQ
How do I compute a CRC-16 Kermit checksum?
Send a non-empty text string in the text field.
What polynomial and initial value does this use?
CRC-16/KERMIT: reflected poly 0x8408 (normal form 0x1021), initial register 0x0000, input and output reflection, no final XOR. The check vector 123456789 yields 2189.
What happens if I send empty input?
Provide at least one character of text to checksum.
Is CRC-16 Kermit the same as CRC-16 Modbus or CCITT-FALSE?
No. Modbus uses poly 0xA001 and init 0xFFFF. CCITT-FALSE uses init 0xFFFF without the same reflection profile. Kermit yields 2189 for 123456789; those other profiles yield different values.
Can I enter the bytes in hexadecimal?
No. This tool has no hex mode: it checksums the UTF-8 bytes of exactly the text you paste. Numbers are turned into text first, so typing 123456789 checksums those nine characters.
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-kermit \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"123456789"}'const res = await fetch("https://api.kit.forhosting.com/enc/crc16-kermit", {
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-kermit",
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-kermit", 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-kermit", 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_kermit",
"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 zero-length payload with a successful checksum.
What CRC-16 Kermit is and when to use it
Do not confuse this profile with CRC-16/CCITT-FALSE (init 0xFFFF, no reflection), CRC-16/XMODEM, or CRC-16/MODBUS (poly 0xA001, init 0xFFFF)—those share family names but produce different residuals for the same payload.
Input contract, empty input, and response fields
The string is encoded as UTF-8 and every resulting byte enters the CRC; there is no separate hex mode in this capability—paste the literal text you want checksummed. Numbers and booleans are accepted by stringifying them first, which keeps simple calculator demos convenient. Failed validation is not billed. Pin the known vector one-two-three-four-five-six-seven-eight-nine equals two one eight nine in regression suites so a poly or reflection typo never ships. POST a JSON body with required string field text. Empty text, including a zero-length string after you omit meaningful content, is rejected with invalid_input and a message that reports empty input so form UIs and API clients can highlight the field without guessing. Missing text, null, or a non-string non-scalar value also fail with invalid_input. On success the body includes crc_hex as four uppercase hexadecimal digits of the full sixteen-bit residual, crc_int as the unsigned integer from zero through sixty-five thousand five hundred thirty-five, byte_count of the UTF-8 payload, and fixed algorithm, poly, and init strings documenting CRC-16/KERMIT with reflected poly 0x8408 and init 0x0000. Alias keys data, payload, value, and input are accepted for the payload field so SDK clients and legacy form posts keep working.
Where a CRC-16 Kermit API earns its keep
Backend services stamp short text frames or configuration blobs with the residual and recompute on receive to catch accidental corruption without standing up a full cryptographic hash. Protocol authors embed the call while porting a Kermit or CCITT-reflected stack and confirm that device code, a C table, and this endpoint all emit the same crc_hex before they ship silicon or crates. Content sites that rank for CRC-16 Kermit checksum or reflected CCITT calculator gain a live tool whose free browser path matches the prepaid automation path exactly, which builds trust when readers compare against offline utilities and datasheets. Pair crc_hex with logging when you need a single printable token, or use crc_int when you store the residual as an unsigned sixteen-bit integer in firmware. Keep requests deterministic, reject empty payloads at the edge, and you get Kermit-grade reproducibility without embedding CRC tables in every microservice.
Integration use cases
Kermit and serial frame checks
Compute CRC-16/KERMIT over payload text and compare crc_hex to the trailer on the wire so Kermit-style or reflected-CCITT frames validate without a local CRC table.
Library and firmware golden checks
Assert that device code and server tooling both produce crc_hex 2189 for ASCII 123456789 and match your fixed regression templates for reflected CCITT.
SEO calculator and support docs
Offer a live CRC-16 Kermit checksum page for engineers who search for the reflected CCITT residual, with free browser execution matching the prepaid API.
Technical questions
What does the CRC-16 Kermit checksum tool cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.