System V sum checksum
The word hello gives checksum 532 and 1 block, exactly what sum -s prints on Unix. Paste text to reproduce the classic System V figure, not the BSD rotate-and-add one, for legacy scripts, documentation and lessons. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- hello
- Checksum
- 532
- Blocks
- 1
- Byte count
- 5
- Algorithm
- System V sum (sum -s)
System V sum is the alternate file checksum algorithm printed by the classic Unix sum utility when you pass the -s switch, the path used on many System V derived systems and still available in GNU coreutils.
What System V sum is and how it differs from BSD sum and modern digests
The System V algorithm accumulates every input byte into a running total, then folds that total into sixteen bits by adding the high half to the low half twice so that overflow from the first fold is absorbed by the second. The result is a non-negative integer in the range zero through sixty-five thousand five hundred thirty-five, historically printed as a decimal checksum next to a block count.
Blocks are not the logical record size of a database; they are five hundred twelve byte units, rounded up, so a five byte string still counts as one block and an empty file counts as zero. This profile is exactly what GNU sum implements with sum -s and what many shell scripts still scrape when they compare two copies of a small file on old Unix hosts. It is deliberately weak by modern standards: collisions are easy and it does not replace SHA-256, CRC-32, or cryptographic message authentication.
Its job is interoperability with sum -s, with archival documentation that quotes System V checksums, and with teaching materials that contrast the BSD rotate-and-add algorithm against the System V plain sum.
When a System V checksum still matters
Embedded and industrial teams that inherited System V style integrity checks in protocol notes can verify short command strings without installing full coreutils on every build image. Educators and documentation sites that rank for System V sum or sum -s checksum gain a live calculator whose free browser path matches the automation path byte-for-byte, including the empty-file edge case that confuses students when they first run sum -s on /dev/null or an empty touch file.
Content authors writing about BSD versus System V algorithms can show both residuals side by side by pairing this capability with a separate BSD path when available, without claiming that either is a cryptographic hash. Failed validation does not consume balance. Pin hello equals five hundred thirty-two with one block and empty equals zero with zero blocks in regression suites, and you get reproducible legacy checksums for scripts, LMS demos, and edge workers without standing up a Unix userspace just to call sum.
What you can do with it
CI goldens for empty and short inputs
Assert checksum 0 and blocks 0 for empty text, and pin known vectors such as hello → 532 / 1 block, so refactors cannot silently change the algorithm.
Teaching BSD vs System V sum
Show students the System V residual and block count next to documentation of the alternate sum algorithm, with a clear empty-input notice for the zero-length case.
FAQ
Is this the same as sum -s?
Yes. It implements the System V alternate algorithm used by sum -s: byte sum, two 16-bit folds, and ceil(length/512) blocks. It is not the BSD default sum algorithm.
Is System V sum a secure hash?
No. It is a legacy 16-bit checksum for interoperability with sum -s and teaching. Use cryptographic digests such as SHA-256 when you need collision resistance.
How is the System V sum checksum calculated?
Every byte of the text is added to a running total. That total is then folded into 16 bits by adding its high half to its low half, twice, so any overflow from the first fold is absorbed by the second. The result runs from 0 to 65535.
What does the block count mean?
It is the number of 512-byte units the text fills, rounded up. A five-letter word such as hello still counts as 1 block, and empty text counts as 0 blocks with a checksum of 0.
How are accented letters and emoji counted?
The text is turned into UTF-8 bytes first, and every byte enters the total. A character that takes several bytes, like an accented letter or an emoji, therefore adds more than one value to the sum.
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/sysv-sum \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"hello"}'const res = await fetch("https://api.kit.forhosting.com/enc/sysv-sum", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "hello"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/sysv-sum",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "hello"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/sysv-sum", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"hello"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"hello"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/sysv-sum", 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": "hello"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.sysv_sum",
"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
Unlike cryptographic hashes, it is a compact sixteen-bit residual plus a count of five-hundred-twelve-byte blocks, designed for quick integrity checks of short payloads and legacy scripts that still parse sum output. This capability accepts a text string, encodes it as UTF-8, runs the same accumulation and fold steps that sum -s applies to file bytes, and returns the checksum together with the block count and byte length. Empty input is accepted on purpose and reported clearly: checksum zero, zero blocks, and an explicit empty notice so automation never confuses a blank payload with a missing field.
What System V sum is and how it differs from BSD sum and modern digests
Use this endpoint when you need that specific residual, not when you need collision resistance. When empty text arrives, the residual is zero and the block count is zero, which matches sum -s on an empty file and is surfaced with an empty_notice field so clients can show a human-readable status without inventing their own wording.
Input contract, response fields, and empty versus missing text
The string is encoded as UTF-8 and every resulting byte enters the System V accumulator; multi-byte Unicode characters contribute every UTF-8 code unit, not a single code point. Example: the five ASCII letters hello yield checksum five hundred thirty-two, one block, and five bytes, matching sum -s. POST a JSON body with required string field text. Alias keys data, payload, value, input, and content are accepted for the same payload so generators and form posts can reuse existing field names. A completely missing text field, a null value, or a non-string object fails with invalid_input and a message that names the missing or invalid field—those failures are not billed and must not be confused with the empty-success path. On success the body always includes checksum as the sixteen-bit residual, blocks as the five-hundred-twelve-byte block count, byte_count of the UTF-8 encoding, empty as a boolean, algorithm as the fixed label System V sum (sum -s), and block_size five hundred twelve. The optional empty_notice appears only when empty is true, following the rule that optional fields are omitted rather than set to null. Keep payloads modest for browser use; the algorithm is linear in byte length and entirely in-memory with no network or file system access.
Integration use cases
Legacy sum -s verification
Recompute System V checksums and 512-byte block counts for short text payloads so modern tools match historic sum -s output in migration and audit scripts.
Technical questions
How do I compute a System V sum checksum?
Send a JSON string field text (UTF-8). The API returns checksum (0–65535), blocks of 512 bytes, byte_count, empty, and algorithm System V sum (sum -s).
What happens with empty input?
Empty string is valid. You get checksum 0, blocks 0, byte_count 0, empty true, and empty_notice describing empty input. Missing text is invalid_input and is not billed.
What does the System V sum 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.