We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Generate Adler32 checksums for strings. Supports Text, Hex, and Base64 inputs for fast data integrity verification.
Enter content to start calculation
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
Adler-32 is a 32-bit checksum: a compact value used to compare data and notice many accidental changes. This page accepts pasted text and displays an uppercase hexadecimal result. It recalculates as the text changes; it does not accept a file, a Hex byte string, or Base64 input.
The standard algorithm maintains two sums. Starting with A = 1 and B = 0, each input byte updates A by adding its value modulo 65,521, then updates B by adding the new A modulo 65,521. The result is B × 65,536 + A. The RFC defines this over bytes. This page instead feeds each JavaScript UTF-16 code unit from the text into the calculation, so its result is not guaranteed to match an implementation that first encodes text as UTF-8 bytes, especially for non-ASCII text.
A₀ = 1; B₀ = 0
Aᵢ = (Aᵢ₋₁ + xᵢ) mod 65,521
Bᵢ = (Bᵢ₋₁ + Aᵢ) mod 65,521
Adler-32 = B × 65,536 + A
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Paste or type the text to compare. Capitalization, spaces, punctuation, and line breaks all affect the result.
A nonempty input produces an eight-character uppercase hexadecimal display for ordinary inputs. Use the copy control to copy the shown result.
Make sure both copies use the same characters and line endings. If comparing with a byte-oriented program, check its encoding and implementation against the page’s character-code behavior first.
For the ASCII word hello, this page displays 062C0215, matching the RFC byte calculation because each character is a single ASCII byte with the same value.
Use cases
See how the tool fits into real work and everyday tasks.
Generate a checksum for a small ASCII snippet, then compare it with another copy processed under the same character and line-ending conventions.
A developer or tester can record a known sample and result to detect accidental edits during a manual handoff. Recheck the actual text if results differ.
Q&A
Find concise answers to common questions and confusing cases.
No. It is a checksum, not encryption, authentication, or a cryptographic hash. Anyone who can change data can also calculate a new checksum.
The RFC algorithm consumes bytes, while this page processes JavaScript UTF-16 code units from the entered string. ASCII characters line up with single-byte values; other characters may not. Use a byte-oriented Adler-32 implementation when a file or protocol specifies exact bytes.
No. It has a text input only. It does not read files or accept encoded byte sequences.
Notes
Review scope, result limitations, and important precautions before use.
Adler-32 is designed for accidental-error detection, not protection against an intentional change. Matching checksums do not prove that two inputs are identical or establish who created them. Use a cryptographic hash or authenticated mechanism when security or provenance matters.
The exact input representation matters. Unicode text can have multiple byte encodings or code-unit sequences, and line-ending conversions can change a checksum. This display also uses JavaScript bitwise operations when combining the two sums; for sufficiently large inputs, the signed 32-bit display behavior can differ from the conventional unsigned eight-digit notation. For standards conformance, use a byte-oriented implementation and confirm the expected output format.
Related
Discover related tools, collections, and available API capabilities.