Check data against a digest in one request
Post a JSON body with three fields. data is the original content, hash is the digest you are checking against, and algorithm names the function that produced it.
curl -X POST https://aisenseapi.com/services/v1/hash_verify \
-H "Content-Type: application/json" \
-d '{"data":"Hello world","hash":"3e25960a79dbc69b674cd4ec67a72c62","algorithm":"md5"}'{"match":true,"algorithm":"md5","computed":"3e25960a79dbc69b674cd4ec67a72c62"}The reply answers your question and shows its work. match is the verdict. computed is the digest the service actually derived from your data.
A mismatch is a normal HTTP 200 result rather than an error. Change one letter of the input and every character of the digest moves, which the computed field makes visible.
curl -X POST https://aisenseapi.com/services/v1/hash_verify \
-H "Content-Type: application/json" \
-d '{"data":"Hello World","hash":"3e25960a79dbc69b674cd4ec67a72c62","algorithm":"md5"}'{"match":false,"algorithm":"md5","computed":"b10a8db164e0754105b7a99be72e3fe5"}Only the capital W changed. Nothing in the digest survived it.
The free hash verify API endpoint asks for no key and no account. The base URL is https://aisenseapi.com/services/v1 and the service-wide limit is 5000 requests per IP per 24 hours.
What the free hash verify API endpoint returns
| Field | Type | Description |
|---|---|---|
| match | boolean | True when the digest computed from data equals the hash you sent. The comparison runs in constant time. |
| algorithm | string | The algorithm actually used, echoed back so a caller that builds requests dynamically can confirm it asked for what it thinks it asked for. |
| computed | string | The digest the service derived from your data. On a mismatch this is the useful half of the answer, because you learn what the value really was instead of only that it was wrong. |
| error | string | Returned when there is nothing to compare. A body with no hash field gives No hash to verify against. Send JSON with "data" and "hash" fields. |
Read the algorithm field rather than assume it. The service recognises the digest from the shape of the hash you send, so this field reports which function produced the match, not merely which one you asked for.
Wider digests work the same way. A SHA256 value is 64 hex characters and returns the same three fields.
curl -X POST https://aisenseapi.com/services/v1/hash_verify \
-H "Content-Type: application/json" \
-d '{"data":"Hello world","hash":"64ec88ca00b268e5ba1a35678a1b5316d212f4f366b2477232534a8aeca37f3c","algorithm":"sha256"}'{"match":true,"algorithm":"sha256","computed":"64ec88ca00b268e5ba1a35678a1b5316d212f4f366b2477232534a8aeca37f3c"}How a naive comparison leaks the answer
Comparing two digests looks like a one-line problem. That is exactly why it goes wrong so often.
The obvious way to do it is a plain string equality check. Every fast string comparison in every language works the same way: it walks the two values and returns the moment it finds a byte that differs. A value whose first character is wrong is rejected sooner than a value whose first twenty characters are right.
That difference is tiny. It is also real, and it is measurable.
Picture an attacker guessing a webhook signature. She sends every possible first character and times each reply. One of those replies comes back a hair slower than the rest, because that guess got one byte further into the loop before failing. She keeps that character and starts work on the second.
Now the cost of the attack has collapsed. Instead of guessing the whole digest at once, the attacker pays for one character at a time, so the work grows with the length of the value rather than exponentially in it. A 64-character digest becomes a few thousand timed attempts plus enough repeats to average out network noise.
This is the classic timing side channel, and it is not exotic. It turns up in signature checks, token comparisons and download verifiers written by careful people in a hurry, because the leaking version is the one that looks obviously correct.
What constant time actually does
The fix is not a faster comparison. It is a comparison that refuses to finish early, and the free hash verify API endpoint takes that route on every call.
- Hash the data
The service computes the digest of
datausing the algorithm you named. - Compare every byte
The computed digest and your
hashgo through a routine that always inspects the whole value and accumulates the differences, instead of returning at the first one it finds. - Answer at a fixed cost
A wrong first character costs exactly what a wrong last character costs, so the response time carries no information about how close the guess was. There is nothing left to measure.
Reach for this endpoint whenever the digest you compare against is a secret, such as a webhook signature or an authentication token. For a public checksum published next to a download the timing does not matter, but the constant-time path costs you nothing either way.
Supported algorithms
| Value | Digest length | Notes |
|---|---|---|
| md5 | 32 hex characters | Still everywhere in file checksums and legacy integrations. Broken for collision resistance, so treat it as a transfer error check rather than a security guarantee. See the MD5 hash API endpoint. |
| sha1 | 40 hex characters | Common in older signature schemes and in version control. Also collision broken, and kept here for systems that still publish SHA-1 digests. See the SHA-1 hash API endpoint. |
| sha256 | 64 hex characters | The sensible default for anything new: release checksums, webhook signatures and integrity records. See the SHA-256 hash API endpoint. |
| sha512 | 128 hex characters | A wider digest from the same family, useful when a counterpart already specifies it. See the SHA-512 hash API endpoint. |
Length is the giveaway. Each function produces a fixed number of hex characters, so the shape of the value you send already narrows down which algorithm made it.
Where the free hash verify API endpoint earns its place
Any comparison against a secret digest belongs here. So does any comparison you would rather not write twice in two languages and keep in step.
Downloaded file check
Compare a file you fetched against the digest the publisher put on the release page, before you trust it or unpack it.
Webhook signatures
Verify the signature on an incoming payload without hand rolling the comparison, which is the exact place a naive equality check leaks timing.
Archive integrity
Confirm that a backup still hashes to the value recorded when it was written, so silent corruption shows up while you can still act on it.
Agent-side verification
Let a language model confirm that data it received matches an expected digest, without handing it any hashing code of its own to get wrong.
Need a short integer checksum instead of a digest? The CRC32 checksum API endpoint covers error detection alone, and every digest function on this page is listed together on the hashing APIs hub.
Privacy and limits
The data and the digest travel in the POST body, not the URL, so neither one ends up in a request path or a server access log line.
Send a secret digest over a network call only when the convenience is worth it. A constant-time comparison is a short function in every language, and running it locally keeps the secret on your own machine.
No account and no API key stand between you and the free hash verify API endpoint. The service-wide limit is 5000 requests per IP per 24 hours, shared across the whole catalogue of free public REST APIs.