SHA-256 & CRC32 off the main thread

Gigabyte hashing runs in an inline Web Worker so the UI stays responsive during the computation. CRC32 uses an 8x faster 256-entry table-driven algorithm; SHA-256 calls crypto.subtle.digest inside the worker. A CSP-safe main-thread fallback kicks in automatically when Workers or Blob URLs are blocked.

What you should see: SHA-256 computed in a Web Worker, so hashing a large file does not freeze the tab. The hash is shown per file before upload and can be used for de-duplication or integrity checks.

Drag & drop files here, or paste from clipboard

Try it: pick a large file. While it hashes, scroll or interact with the page - the UI never freezes. The computed hash lands on task.hash and is sent to the server with the upload.

Configuration

CoreUpload.create('#uploader', {
 uploadUrl: '/api/upload/upload',
 computeHash: true,
 hashAlgorithm: 'sha256' // or 'crc32'
});

Use cases

Content-addressable storage: use the hash as the storage key so identical uploads de-dupe.
Integrity verification: re-hash on the server and compare to catch corruption.
Duplicate detection: reject files already in the queue by hash, not by name.
Signature workflows: sign the hash rather than the bytes for document signing flows.

Fallback behaviour

When Workers or Blob URLs are unavailable (strict CSP, older browsers), hashing transparently runs on the main thread. The API and the resulting task.hash value are identical; only UI responsiveness during the hash differs.

Worker implementation

The worker body is inlined via Blob + URL.createObjectURL so no extra file needs to be served. One short-lived worker per hash call; terminated immediately after postMessage.