BSD checksum calculator
The text “abc” gives a BSD checksum of 16556, or 40ac in hex, in 1 block: the same pair the old Unix sum command prints in BSD mode. Useful for checking legacy scripts, tape labels and textbook exercises. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- abc
- Result
- 40ac
- Checksum
- 16,556
- Hex
- 40ac
- Decimal
- 16,556
The classic BSD sum algorithm is the sixteen-bit rotate-and-add checksum used by the historic Unix sum command in its BSD mode (often invoked as sum -r on GNU systems). Unlike cyclic redundancy checks, it updates a single sixteen-bit register by rotating right one bit and adding each message byte, then reports a block count in units of one thousand twenty-four bytes. Engineers comparing legacy tape labels, students reproducing textbook sum output, and support teams verifying short text blobs against old scripts often need the same deterministic pair: the unsigned checksum value and the block column. This BSD checksum tool accepts non-empty text, encodes it as UTF-8, runs that rotate-and-add loop, and returns the sixteen-bit value as decimal and four lowercase hexadecimal digits together with the block count, the algorithm label, the byte length, and a short summary.
What the classic BSD sum computes and why the block count matters
The BSD checksum treats every message as a sequence of bytes and maintains one sixteen-bit accumulator that starts at zero. For each byte, the register is first rotated right by one bit within sixteen bits—so the least significant bit moves into the high bit—and then the byte value is added, with the sum masked back to sixteen bits. When the stream ends, that unsigned integer is the checksum column of the classic sum output.
Because BSD sum is not collision-resistant and not keyed, treat it as a fast legacy integrity or framing check, not as proof of authenticity; prefer SHA-family digests when the search intent is cryptographic hashing rather than the classic rotate-and-add checksum.
Where a BSD checksum is still worth using
Legacy systems authors and Unix history students use a BSD checksum calculator to verify hand-computed rotate-and-add steps against sum -r without installing a full coreutils environment in every language. Teaching platforms and LMS plugins need a deterministic oracle that rejects empty input instead of returning zeros for the empty message, so auto-graders can distinguish missing answers from a real checksum.
Content sites ranking for BSD checksum, sum command checksum, or classic Unix sum 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 System V sum, CRC-16, or cryptographic hash landings only when the search intent moves beyond classic BSD rotate-and-add—keep this page focused on BSD sum so SEO intent stays sharp and does not cannibalize Adler-32 or CRC-16 landings.
FAQ
Which algorithm does this match?
The classic BSD sum used by historic Unix sum and by GNU coreutils sum -r: for each byte, rotate the sixteen-bit register right by one bit, then add the byte; block count is ceil(length/1024).
What happens if the text is empty?
A non-empty string is required; empty input is not treated as a successful checksum of zero with zero blocks.
Is the BSD checksum calculator free?
The browser tool runs free on your device.
Is BSD sum the same as System V sum or CRC-16?
No. System V sum (-s) uses a different accumulation and 512-byte blocks. CRC-16 uses a polynomial register. This tool implements only classic BSD rotate-and-add.
What does the block count in the result mean?
It is the number of 1024-byte blocks the text fills once encoded as UTF-8, rounded up. Anything from 1 to 1024 bytes counts as one block, and the next kilobyte starts a second one.
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/bsd-sum \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"abc"}'const res = await fetch("https://api.kit.forhosting.com/enc/bsd-sum", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "abc"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/bsd-sum",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "abc"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/bsd-sum", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"abc"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"abc"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/bsd-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": "abc"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.bsd_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
Empty input is rejected with invalid_input so callers never confuse a missing field with the zero-zero empty-file report of the classic command.
What the classic BSD sum computes and why the block count matters
Alongside it, the tool reports how many one-thousand-twenty-four-byte blocks the message occupies, using ceiling division of the UTF-8 length: any non-empty payload of one to one thousand twenty-four bytes yields one block, the next kilobyte starts a second block, and so on.
Input contract, empty-string errors, and the JSON response shape
The string is encoded as UTF-8 before the BSD loop, so multi-byte characters contribute every code unit byte exactly as a file-oriented sum would if it received the same UTF-8 stream. Empty input is deliberately rejected rather than returning the theoretical empty-file pair zero zero, so product UX and auto-graders can distinguish missing answers from a real checksum. Pin both a success path and an empty-input error in continuous integration so accidental rotate direction or block-size 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 and hex set to the same four-digit lowercase hexadecimal checksum; checksum and decimal set to the unsigned sixteen-bit integer; blocks set to the one-thousand-twenty-four-byte block count; algorithm fixed at BSD sum; input_bytes equal to the UTF-8 length; text echoing the input; and message summarizing the byte count, decimal value, hex, and blocks.
Where a BSD 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. 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.
Integration use cases
Legacy sum -r verification
Reproduce the classic BSD checksum and 1024-byte block count for a short text payload when migrating scripts that still print the historic sum -r pair.
Classroom rotate-and-add demos
Teachers show how a sixteen-bit right rotate plus add yields the well-known abc and Hello fixtures without installing coreutils on every student machine.
CI fixtures for legacy integrity helpers
Pipelines pin deterministic BSD sum decimal, hex, and blocks outputs plus the empty-input error so accidental rotate or block-size changes fail fast.
Technical questions
How do I compute a BSD checksum of text?
Send JSON with a non-empty string field text. The API UTF-8-encodes the string, runs the classic BSD sum rotate-and-add loop, and returns the sixteen-bit value as decimal and four lowercase hex digits plus the 1024-byte block count.