Free SHA1 Hash API Endpoint

Hash a string with the free SHA1 hash API endpoint

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

{"sha1_hash":"7b502c3a1f48c8609ae212cdfb639dee39673f5e"}

SHA-1 is a 160-bit digest function. Printed as hexadecimal, 160 bits is always 40 characters. That width never changes with the size of the input. One byte and one gigabyte both come back as exactly 40 characters.

There is no key to fetch and no account to create. The base URL for every call is https://aisenseapi.com/services/v1, and the service-wide limit is 5000 requests per IP per 24 hours.

Do not use SHA-1 for security

A collision means an attacker can build two inputs that produce the same 40 characters. Any use that depends on a digest being unforgeable falls apart at that point. A signature over a SHA-1 digest also covers the attacker's second document. A SHA-1 fingerprint stops proving which file you actually hold.

Reach for the SHA-256 hash API endpoint whenever an adversary sits anywhere in your threat model. Passwords are a separate problem again. No plain digest suits them, SHA-256 included. Password storage needs a slow salted function such as bcrypt, scrypt or Argon2, run inside your own application.

Why the endpoint still matters

Unfit for new security designs is not the same as gone. SHA-1 is the identifier format of git. Every commit, tree, blob and tag in a classic repository is named by the SHA-1 of a small header followed by the object bytes. The header is the object type, a space, the byte length, then a NUL byte.

printf 'blob 11\0Hello world' > object.bin
curl -X POST https://aisenseapi.com/services/v1/sha1_hash \
  -F "file=@object.bin"

{"sha1_hash":"70c379b63ffa0795fdbfbc128e5a2818397b7ef8"}

Those are the same 40 characters git hash-object reports for a file holding the eleven bytes Hello world. Reproducing an object id outside git is an ordinary need. It comes up while auditing a mirror, while checking what a hook received, and while building tooling that has to address objects the way git does.

Legacy protocol handshakes are the second reason the free SHA1 hash API endpoint stays online. Older handshakes derive values from a SHA-1 digest, and SSH and TLS tooling still prints SHA-1 fingerprints beside newer ones. Computing a digest so you can compare it against what a legacy peer produced is a legitimate need, and refusing to compute it makes nothing safer.

Older API signatures are the third. Long-lived services sign a request by hashing a canonicalised string, and plenty of them key their records by the SHA-1 of a normalised value. Matching an existing row means reproducing that exact digest, whatever the cryptographic standing of the algorithm.

Response fields

Every successful call to the free SHA1 hash API endpoint returns a single field. Errors return a single field too.

Empty input is refused rather than answered with the SHA-1 of the empty string. That digest is a well known constant. Returning it quietly would hide the common caller bug where a variable never got filled in.

Three ways to send the input

All three forms hash the same bytes and return the same digest. Pick whichever suits the caller.

curl -X POST https://aisenseapi.com/services/v1/sha1_hash \
  -H "Content-Type: text/plain" \
  --data-binary "Hello world"

{"sha1_hash":"7b502c3a1f48c8609ae212cdfb639dee39673f5e"}

A file upload uses multipart/form-data and hashes the file content, never the filename or the form metadata. Here report.txt holds the eleven bytes Hello world with no trailing newline.

curl -X POST https://aisenseapi.com/services/v1/sha1_hash \
  -F "file=@report.txt"

{"sha1_hash":"7b502c3a1f48c8609ae212cdfb639dee39673f5e"}

Compare against an expected digest

POST /hash_verify takes the data and the digest you expect, then answers whether the two agree. The comparison runs in constant time, so the answer takes the same amount of time whether the first character differs or only the last one does. It recognises the algorithm from the length and shape of the hash itself, which is why one endpoint covers every digest listed on the hashing APIs hub.

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

{"match":true,"algorithm":"sha1","computed":"7b502c3a1f48c8609ae212cdfb639dee39673f5e"}

A mismatch is a normal HTTP 200 result rather than an error. The computed value always comes back, so you can see what the data really hashes to. Changing one letter of the input is enough to break the match.

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

{"match":false,"algorithm":"sha1","computed":"0a4d55a8d778e5022fab701977c5d840bbc486d0"}

Full details of that call live on the hash verify API endpoint page. Constant-time comparison does not repair SHA-1, however. A careful comparison of a forgeable digest is still a forgeable digest.

Common uses

Privacy and limits

Input travels in the POST body rather than the URL, so it never lands in a request path. If the value is confidential, compute the digest inside your own application instead. Every language ships a SHA-1 implementation, and hashing needs no network call at all.

The free SHA1 hash API endpoint asks for no key and no account, and the limit stays at 5000 requests per IP per 24 hours. The full catalogue sits on the free public REST APIs page.

Related APIs