ForHosting KIT · Developer Utilities

Hash a string

Hashing looks like a one-line function call until you need it consistently across a fleet of services, in bulk, with the right algorithm for the right job.

● StableFree · in your browser
Use it from WebAPIEmailTelegramApp soon

This sha256 hash api generates SHA-256, SHA-512, SHA-1 and MD5 digests, plus salted bcrypt password hashes, on request, so integrity checks, fingerprints and password storage don't depend on every service reimplementing the same primitive correctly.

Six algorithms, different jobs

SHA-256, SHA-384 and SHA-512 are cryptographic hash functions built for integrity verification and digital signatures, fast by design, which is exactly why they're the wrong tool for passwords, a fast hash means an attacker can try billions of guesses per second. SHA-1 is still accepted for compatibility but is deprecated for any security use since collisions became practical. MD5 is faster still and considered broken for any security purpose since practical collision attacks were demonstrated in 2004, it survives today only for non-adversarial checksums like verifying a file wasn't corrupted in transit. Bcrypt inverts the premise of all of them: it's deliberately slow, with a tunable work factor and a random salt built into every hash, because making each guess expensive is the entire point when the thing being protected is a password.

What POST /dev/hash does

You send the input string and the desired algorithm, and you get back the digest as lowercase hexadecimal, except for bcrypt, which returns its standard 60-character string with the salt and work factor embedded, ready to store and verify as-is. The request shape is identical for every algorithm, only the algorithm field changes, so switching from SHA-256 to SHA-512, an MD5 legacy checksum, or a bcrypt password hash never means a different code path on your side.

Where SHA-256 in particular shows up

Published by a national standards body in 2001 as part of the SHA-2 family, SHA-256 became the backbone of an enormous amount of infrastructure that came after it, package managers verifying download integrity, git's move toward SHA-256 object storage, and countless systems that need a fixed-length fingerprint of arbitrary data. Its popularity isn't accidental, it strikes a practical balance between security margin and computational cost that has held up for over two decades.

How it fits an automated pipeline

Deduplication systems that fingerprint files before storing them, build systems that verify artifact integrity before deployment, signup flows that hash a password with bcrypt before it ever touches a database, and content-addressed caches that key on a digest all call this endpoint the same way: submit, get a task_id back, and receive the result through a signed webhook or a signed link valid for 24 hours. Bulk requests, hashing a large batch of records during a migration, run the same way without a special code path.

Picking the right one

If you're verifying data integrity or generating a fingerprint, SHA-256 is the sound default and SHA-512 is available when a longer digest is worth the extra bytes. SHA-1 and MD5 exist here for compatibility with legacy systems that still expect them, not as a recommendation for anything security-sensitive. And if you're protecting a password, bcrypt is the right choice: a deliberately slow, salted password hash, the opposite of the fast integrity digests, with a work factor you can raise as hardware gets faster.

Password hashing for signup flows

Hash a new user's password with bcrypt before it's written to your database, with the salt and work factor already embedded in the 60-character output and verified later with a constant-time compare.

Content-addressed fingerprints

Generate a SHA-256 digest to key files or records in a content-addressed store, so identical inputs always map to the same fingerprint and duplicates collapse on their own.

File integrity verification

Generate a SHA-256 digest for uploaded files so downstream systems can confirm the file wasn't altered before processing it.

Bulk deduplication

Hash a large batch of records in one call to identify duplicates by comparing digests instead of full field-by-field content.

Legacy checksum compatibility

Produce an MD5 checksum for integration with an older system that still expects that specific format for non-security file verification.

Which algorithms does this sha256 hash api support?

SHA-256, SHA-384, SHA-512, SHA-1 and MD5, each returned as a lowercase hexadecimal digest, plus bcrypt, returned as its standard salted 60-character string for password hashing.

Should I use SHA-256 to hash passwords?

No. SHA-256 is fast by design, which makes it unsuitable for passwords. For passwords, choose the bcrypt algorithm this endpoint offers: it's deliberately slow and salted, so every guess is expensive for an attacker.

How is bcrypt different from the other algorithms?

Bcrypt is a password-hashing function, not a fast integrity hash. It builds a random salt into every hash and lets you set a work factor (cost, clamped to 4 to 15), so the same password yields a different 60-character output each time and verification is a constant-time compare. Use it for passwords; use SHA-256 for fingerprints and integrity.

Is MD5 still safe to use?

Not for any security purpose, practical collision attacks have been demonstrated since 2004. It's included here for compatibility with legacy checksum needs, not as a security recommendation.

Can I hash data in bulk?

Yes, since tasks run asynchronously, you can submit large batches for hashing without blocking your application while results are generated.

Is there a free tier?

The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.

How much does each request cost?

$0.002 per request, charged only for tasks that complete successfully.

How do I get the hash back?

POST /dev/hash returns a task_id immediately, and the result is delivered via signed webhook or a signed link valid for 24 hours.

Which algorithm should I pick for a fingerprint?

SHA-256 is the default choice for fingerprints and integrity checks: fixed length, widely supported, and a security margin that has held up for over two decades. Reach for SHA-512 only when a longer digest is worth the extra bytes.

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.

POSThttps://api.kit.forhosting.com/dev/hash

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.

curl -X POST https://api.kit.forhosting.com/dev/hash \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"hola mundo"}'
{
  "text": "hola mundo"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.hash",
  "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.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

Read the full KIT documentation →