Why hash generator privacy matters

Developers hash sensitive data for a reason: to protect it. Sending that same data to a server-based hash generator undermines the entire purpose. If you are hashing a password to compare against a stored hash, sending the plaintext password to a third-party server exposes it. If you are generating a checksum for a confidential file, uploading the file contents defeats confidentiality. DevBolt hashes everything locally using the Web Crypto API — your plaintext input stays on your device, and only the hash output exists in your browser.

How browser-based hashing works

DevBolt uses the SubtleCrypto.digest() method from the Web Crypto API for SHA-1, SHA-256, SHA-384, and SHA-512. This is the same hashing implementation your browser uses for TLS certificate verification and Subresource Integrity checks — it is hardware-accelerated on most modern processors. For MD5, DevBolt uses a pure JavaScript implementation since MD5 is not included in the Web Crypto API. All computation happens in your browser's JavaScript engine.

// JavaScript — SHA-256 hash using Web Crypto API (same as DevBolt)
async function sha256(text) {
  const data = new TextEncoder().encode(text);
  const hash = await crypto.subtle.digest('SHA-256', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0')).join('');
}
await sha256('hello world');
// "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9"

# Python — equivalent local hashing
import hashlib
hashlib.sha256(b'hello world').hexdigest()
# "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9"

Common sensitive data that gets hashed

Passwords before database storage, file checksums for integrity verification, API request signatures (HMAC), content-addressable storage keys, de-duplication hashes for sensitive documents, and git commit hashes. Each of these involves data that should remain confidential. A client-side hash generator ensures the plaintext input never crosses a network boundary.