CRC-64 checksum
The nine characters 123456789 give the CRC-64/ECMA-182 value 6C40DF5F0B497347, the reference check for this profile, so a library that returns anything else is not ECMA-182. Paste any text to get its 64-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
- 6C40DF5F0B497347
- Crc hi
- 6C40DF5F
- Crc lo
- 0B497347
- Byte count
- 9
CRC-64 with the ECMA polynomial is a sixty-four-bit cyclic redundancy check used when you need a stronger residual than CRC-32 without jumping to a cryptographic hash. Storage systems, archival tools, and protocol designers rely on CRC-64/ECMA-182 to detect accidental corruption in buffers, file segments, and framed messages. This capability takes a non-empty text string, encodes it as UTF-8, runs the standard ECMA-182 algorithm with polynomial 0x42F0E1EBA9EA3693 and initial value zero, and returns the residual as sixteen uppercase hexadecimal digits.
What CRC-64/ECMA-182 computes
A cyclic redundancy check folds every byte of a message through a fixed generator polynomial, so a single flipped bit almost always changes the result. The ECMA-182 profile works on a 64-bit register with the polynomial 42F0E1EBA9EA3693, defined around the European Computer Manufacturers Association. The register starts at zero, each byte is mixed into its top eight bits, and there is neither input reflection nor a final mask. Your text is encoded as UTF-8 first, and the residual comes back as sixteen uppercase hexadecimal digits, together with its high and low halves of eight digits each.
When a 64-bit check pays off, and its limits
Storage systems, archiving tools and protocol designers use CRC-64 to catch accidental corruption in buffers, file segments and framed messages, when they want a stronger residual than CRC-32 without moving to a cryptographic hash. To check your own code, run the nine characters 123456789: anything other than 6C40DF5F0B497347 is a different profile. There is no hex input mode, so paste the literal text you want checked; numbers are treated as text. An empty message is rejected. And because a CRC is a public, linear calculation, it is never a substitute for a password hash or a keyed signature.
What CRC-64 ECMA 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-64/ECMA-182 is the sixty-four-bit profile defined around the European Computer Manufacturers Association polynomial 0x42F0E1EBA9EA3693: the register starts at zero, each byte is exclusive-ored into the high eight bits of the sixty-four-bit word, and eight shift-and-conditional-xor steps follow per byte with neither input reflection nor a final exclusive-or mask.
The classic check vector is the nine ASCII digits one through nine, which must yield residual 0x6C40DF5F0B497347; if your library disagrees with that value, it is not ECMA-182 even if it advertises CRC-64. Do not use it as a password hash or as a stand-in for a keyed MAC: cyclic redundancy checks are public linear functions and offer no secrecy or authentication against a motivated attacker.
FAQ
How do I compute a CRC-64 ECMA checksum?
Send a non-empty text string in the text field.
What polynomial and initial value does this use?
CRC-64/ECMA-182: polynomial 0x42F0E1EBA9EA3693, initial register 0x0000000000000000, no reflection, no final XOR. The check vector 123456789 yields 6C40DF5F0B497347.
What happens if I send empty input?
Provide at least one character of text to hash.
Is CRC-64 the same as a cryptographic hash?
No. CRC-64 detects accidental corruption; it is not collision-resistant against an attacker and must not replace SHA-256, HMAC, or password hashing.
When is CRC-64 a better choice than CRC-32?
When the data is large or split into many archive segments. The wider 64-bit residual lowers the risk of an accidental match, yet it stays far cheaper than SHA-256 when you only need protection against noise.
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/crc64 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"123456789"}'const res = await fetch("https://api.kit.forhosting.com/enc/crc64", {
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/crc64",
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/crc64", 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/crc64", 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.crc64",
"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 hash.
What CRC-64 ECMA is and when to use it
Compared with CRC-16 Modbus or CRC-32, the wider residual reduces collision risk for larger payloads and multi-segment archives, yet it stays far cheaper than SHA-256 when you only need integrity against accidental noise, not adversarial collision resistance.
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 literal text you want hashed. Numbers and booleans are accepted by stringifying them first, which keeps simple calculator demos convenient. Failed validation is not billed. 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 sixteen uppercase hexadecimal digits of the full sixty-four-bit residual, crc_hi and crc_lo as the high and low thirty-two-bit halves each as eight hex digits, byte_count of the UTF-8 payload, and fixed algorithm, poly, and init strings documenting CRC-64/ECMA-182 with polynomial 0x42F0E1EBA9EA3693 and init 0x0000000000000000. 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-64 ECMA API earns its keep
Content sites that rank for CRC-64 checksum or ECMA polynomial calculator gain a live tool whose free path matches the automation path exactly, which builds trust when readers compare against offline utilities. Backend authors embed the call in upload pipelines that stamp each chunk with crc_hex before writing object storage, then recompute on download to catch bit rot early. Pair crc_hex with your logging and audit trail when you need a single printable token, or use crc_hi and crc_lo when you store the residual as two unsigned thirty-two-bit integers in languages without native sixty-four-bit types. Keep requests deterministic, reject empty payloads at the edge, and you get archive-grade reproducibility without embedding CRC tables in every microservice.
Integration use cases
Chunk integrity stamps
Hash each uploaded text segment with CRC-64 ECMA and store crc_hex beside the object so readers can recompute and detect corruption without full cryptographic hashing.
Library and firmware golden checks
Assert that device code and server tooling both produce crc_hex 6C40DF5F0B497347 for ASCII 123456789 and match your fixed regression templates.
SEO calculator and support docs
Offer a live CRC-64 checksum page for engineers who search for the ECMA polynomial residual, with free browser execution matching the prepaid API.
Technical questions
What does the CRC-64 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.