Free CRC32 Checksum API Endpoint

Checksum a string in one POST

The free CRC32 checksum API endpoint does the whole job in a single request. There is no key to fetch, no account to create and no header beyond the content type. Post JSON with one data field and read the number that comes straight back.

curl -X POST https://aisenseapi.com/services/v1/crc32_checksum \
  -H "Content-Type: application/json" \
  -d '{"data":"Hello world"}'

{"crc32_checksum":2346098258}

Change one letter and the answer shares nothing with the first one. Capitalize the w in world and the checksum lands somewhere completely different. That sensitivity is the entire point.

curl -X POST https://aisenseapi.com/services/v1/crc32_checksum \
  -H "Content-Type: application/json" \
  -d '{"data":"Hello World"}'

{"crc32_checksum":1243066710}

A request with nothing to checksum is refused. The service does not quietly answer with the checksum of an empty string, which would look like a valid result while hiding a bug in the caller.

curl -X POST https://aisenseapi.com/services/v1/crc32_checksum \
  -H "Content-Type: application/json" \
  -d '{}'

{"error":"No data to hash or invalid input."}

Every value printed on this page came from a live call, so you can paste the commands above and reproduce them yourself.

Response fields

Success returns exactly one field. There is no envelope, no status flag and no metadata to unwrap before you reach the number.

Keep the value as a number in your own code. Parsing it into a string first is where most integration bugs begin.

The free CRC32 checksum API endpoint returns an integer, not hex

Most confusion around CRC32 is about presentation rather than arithmetic. This service answers 2346098258 for the string above. A command line tool or a ZIP inspector will usually print the same checksum as 8bd69e52, because CRC32 is traditionally displayed in hexadecimal. Those are one number written in two bases.

Signedness is the second trap. A CRC32 fills all 32 bits, so any language limited to signed 32-bit integers reports values above 2147483647 as negative. Java's CRC32 class and .NET both hand back the raw bits, and a careless cast turns this checksum into -1948869038. The bits never moved. Add 4294967296 to a negative result, or mask it with 0xFFFFFFFF, and you are back at the number this API returns.

Leading zeros supply a third difference. A small checksum such as 0x0004a3f1 prints as eight hex characters in one tool and as the six-digit decimal 303601 here.

Compare checksums numerically, never as strings

The rule falls out of those three differences. Normalize both sides to an unsigned integer, then compare the numbers.

String comparison fails on base, on sign and on padding, sometimes all at once. Two systems can agree perfectly on a checksum and still disagree on every character of its printed form. Convert to hex only at the very last step, when something downstream truly wants hex, and pad the result to eight characters before you print it.

Here is a quick sanity check while you wire things up. The value must always land between 0 and 4294967295 inclusive. A negative number means somebody read the bits as signed. A value containing letters means somebody handed you hexadecimal. Both are one line away from being fixed.

How the value is produced

Three things happen between your POST body and the number in the response. Knowing them explains almost every surprise.

1. Take the UTF-8 bytes

   The data string is checksummed as UTF-8 bytes. Non-ASCII characters therefore contribute more than one byte each, and the same visible text stored in another encoding produces a different checksum.

2. Run the standard polynomial

   This is the ordinary CRC-32 used by ZIP, PNG and gzip. A value computed by the free CRC32 checksum API endpoint matches what those formats and their tooling compute over the same bytes.

3. Return the unsigned value

   The result leaves as a JSON number in the range 0 to 4294967295. Nothing is padded, prefixed or converted on your behalf.

A checksum is not a cryptographic hash

A checksum detects accidents. Bits flip in memory. A transfer gets truncated. A disk returns a stale sector. A copy script drops the final chunk. Recompute the CRC32 over whatever arrived, compare it with what the sender had, and the mismatch is obvious at once. It costs almost nothing to compute and it fits in four bytes, which is why it sits inside the ZIP format, inside every PNG chunk and inside Ethernet frames rather than in a separate manifest.

What CRC32 cannot do is resist a person. It is a linear function. Given any input, constructing a different input with the same checksum is easy. Anyone able to change the data can change it in a way that keeps the checksum identical, and the check will pass happily.

The dividing line is short. CRC32 answers "did this get damaged". A cryptographic hash answers "did somebody change this". Keep the birthday problem in view as well. With only 32 bits, two unrelated inputs collide roughly once in four billion, so across a set of about 100000 items you should expect one accidental collision. That is fine for spotting corruption in a single known file. It is not fine as a primary key across a large corpus.

Where this endpoint earns its keep

Related hashing endpoints

Checksums and hashes sit on the same shelf, so the free CRC32 checksum API endpoint is documented next to the rest of the hashing APIs. Choose by the job in front of you rather than by habit.

Reach for the MD5 Hash API Endpoint when 32 bits are too few and the threat is still accidental. Move to the SHA-256 Hash API Endpoint once somebody might tamper on purpose, or to the SHA-512 Hash API Endpoint for a wider digest. The SHA-1 Hash API Endpoint still helps when you read legacy systems that already store SHA-1 values. When all you need is confirmation that a digest matches some text, the Hash Verify API Endpoint runs the comparison for you.

Every one of them appears in the catalogue of free public REST APIs, on the same base URL and under the same daily limit.

Privacy and limits

The base URL is https://aisenseapi.com/services/v1 and the service-wide limit is 5000 requests per IP per 24 hours. There is no account and no API key.

Related APIs