Adler-32 checksum calculator
Get the Adler-32 checksum of any text, the two-sum check used inside zlib: Wikipedia gives 11e60398, with A at 920 and B at 4582. Handy for checking compressed data or homework against RFC 1950. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- Wikipedia
- Result
- 11e60398
- Adler32
- 11e60398
- Hex
- 11e60398
- Decimal
- 300,286,872
Adler-32 is a thirty-two-bit checksum designed by Mark Adler and used inside zlib and the DEFLATE family of formats. Unlike a cyclic redundancy check, it maintains two running sums over the message bytes and combines them into a single unsigned integer that is fast to compute on ordinary CPUs.
What Adler-32 computes and why the hex word matters
Adler-32 treats every message as a sequence of bytes and updates two accumulators. The first accumulator, called A, starts at one and adds each byte, reducing modulo sixty-five thousand five hundred twenty-one after each step. The second accumulator, called B, starts at zero and adds the current value of A after every byte, again modulo the same prime.
When the stream ends, the checksum is formed by placing B in the high sixteen bits and A in the low sixteen bits of a thirty-two-bit unsigned integer. That construction is exactly the definition in RFC 1950 and the implementation inside zlib, so the well-known check string Wikipedia produces hexadecimal eleven e six zero three nine eight.
The response also echoes the decimal integer, the separate A and B values, the algorithm label Adler-32, the UTF-8 byte count, and the original text so clients can display a full audit line without re-deriving metadata. Because Adler-32 is not collision-resistant and not keyed, treat it as a fast integrity or framing check, not as proof of authenticity; prefer SHA-family digests when the search intent is cryptographic hashing rather than a zlib-style rolling checksum.
Where an Adler-32 checksum is genuinely useful
Compression authors and zlib students use an Adler-32 checksum calculator to verify hand-computed A and B partials against the RFC 1950 definition without writing a modular sum loop in every language. Teaching platforms and LMS plugins need a deterministic oracle that rejects empty input instead of returning one for the empty message, so auto-graders can distinguish missing answers from a real checksum. Content sites ranking for Adler-32 checksum or Adler32 calculator 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-32 or cryptographic hash landings only when the search intent moves beyond a zlib-style two-sum check—keep this page focused on Adler-32 so SEO intent stays sharp and does not cannibalize CRC-8 or SHA-256 landings.
What you can do with it
Classroom modular-sum demos
Teachers show the classic Wikipedia check value and let students recompute other short strings without installing a compression library.
FAQ
Which Adler-32 parameters does this tool use?
The standard zlib profile: modulus 65521, A starts at 1, B starts at 0, checksum equals (B shifted left 16) or A. The documented check for ASCII Wikipedia is 11e60398.
What happens if the text is empty?
A non-empty string is required; empty input is not treated as a successful checksum of 00000001.
Is the Adler-32 checksum calculator free?
The browser tool runs free on your device.
Is Adler-32 a cryptographic hash?
No. Adler-32 is a fast thirty-two-bit integrity check used by zlib. Use SHA-256 or similar when you need collision resistance or authentication.
Why does the checksum change with accents or emoji?
Because the text is turned into UTF-8 bytes before the sums run, and characters such as é or an emoji take more than one byte. Every one of those bytes counts, exactly as a compressor would see 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/adler32 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Wikipedia"}'const res = await fetch("https://api.kit.forhosting.com/enc/adler32", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "Wikipedia"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/adler32",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "Wikipedia"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/adler32", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"Wikipedia"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"Wikipedia"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/adler32", 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": "Wikipedia"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.adler32",
"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
Engineers verifying compressed payloads, students learning RFC 1950, and support teams comparing trailers from device logs often need the same textbook result for a short string: initial A equal to one, initial B equal to zero, both reduced modulo sixty-five thousand five hundred twenty-one, then B shifted left sixteen bits and combined with A. This Adler-32 checksum tool accepts non-empty text, encodes it as UTF-8, runs that deterministic loop, and returns the full thirty-two-bit value as eight lowercase hexadecimal digits together with the decimal integer, the A and B partials, and a short summary. Empty input is rejected with invalid_input so callers never confuse a missing field with the known empty-message checksum of one.
Input contract, empty-string errors, and the JSON response shape
The string is encoded as UTF-8 before the Adler loop, so multi-byte characters contribute every code unit byte exactly as a compressor would if it received the same UTF-8 stream. Empty input is deliberately rejected rather than returning the theoretical empty-message value zero zero zero zero zero zero zero one, 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 modulus 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, adler32, and hex all set to the same eight-digit lowercase hexadecimal checksum; decimal set to the unsigned thirty-two-bit integer; a and b set to the final low and high sixteen-bit partials; algorithm fixed at Adler-32; input_bytes equal to the UTF-8 length; text echoing the input; and message summarizing the byte count and hex result.
Where an Adler-32 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
zlib and DEFLATE trailer checks
Verify that a payload string produces the expected Adler-32 trailer under RFC 1950 before comparing compressed-stream logs or unit-test vectors.
CI fixtures for integrity helpers
Pipelines pin deterministic Adler-32 hex outputs and the empty-input error so accidental modulus or init changes fail fast.
Technical questions
How do I compute an Adler-32 checksum of text?
Send JSON with a non-empty string field text. The API UTF-8-encodes the string, runs Adler-32 as defined by zlib and RFC 1950, and returns the thirty-two-bit value as eight lowercase hex digits in result, adler32, and hex.