Local-firstYour text never leaves your browser. No upload, no account, no server.
Most online text tools send whatever you paste to a server, run the work there, and send a result back. Your words sit in someone else's logs, backups and databases, and you have to trust a privacy policy.
Local-first means the opposite: the whole tool is downloaded to your browser and runs on your own device. Nothing you type is transmitted anywhere: not to us, not to anyone. There is no server that could receive it, which is a stronger guarantee than a promise not to look.
Three consequences worth knowing:
Paste text and get its cryptographic digest, in hexadecimal or Base64. Hashing runs through WebCrypto: the same primitives the browser uses for TLS, so a password, an API key or a document you are checksumming never leaves the machine. The input is encoded as UTF-8 first, which is what makes the result match the digest a server computes for the same string rather than differing on the first accented character.
The published SHA-256 of "abc"
abc
ba7816bf8f01cfea414140de5dae2223 b00361a396177a9cb410ff61f20015ad
WebCrypto does not implement MD5, and that omission is deliberate on the platform's part. MD5 has been broken for collision resistance since 2004, and producing two different inputs with the same digest now takes seconds on ordinary hardware.
Implementing it by hand so this page could offer it would mean shipping a primitive that looks endorsed by appearing alongside SHA-256. If you genuinely need MD5 to verify a legacy checksum, use a tool built for that, and understand it tells you a file is probably unchanged: not that nobody tampered with it.
SHA-1 is offered here for the same legacy reason, and carries the same caveat: it is broken for collision resistance and must not be used for new signatures or certificates.
A SHA hash is designed to be fast, which is exactly wrong for password storage. Speed is what lets an attacker who has stolen your database try billions of candidate passwords per second against it.
Password hashing needs an algorithm that is deliberately slow and salted per user: bcrypt, scrypt or Argon2. Salting also defeats rainbow tables, which are precomputed digests of common passwords: without a salt, hashing "password123" produces the same digest in your database as in everyone else's.
Use this for integrity: verifying a download, fingerprinting a document, or checking two files match without comparing them byte by byte.
Almost always text encoding. This hashes the UTF-8 bytes of your input, which is what any server or command-line tool does by default. A tool that hashes UTF-16 code units produces a completely different digest for the same visible text, and the two agree perfectly on ASCII, so the divergence only appears the first time someone includes an accent or an emoji.
The other frequent cause is an invisible trailing newline. Hashing a file adds the newline the file ends with; pasting its contents into a text box usually does not. One byte of difference changes every bit of the output, which is the property that makes hashes useful and the reason near-misses tell you nothing.
Because WebCrypto does not implement it, deliberately: MD5 has been broken for collision resistance since 2004 and practical collisions can be produced in seconds. Implementing it by hand so this page could offer it would mean shipping a broken primitive that looks endorsed. If you need MD5 for a legacy checksum, use a dedicated tool and understand it proves nothing about authenticity.
SHA-256 for anything new. SHA-384 and SHA-512 are stronger and no slower on 64-bit hardware, so they are reasonable defaults too. SHA-1 is offered only because you may need to verify an old checksum: it is broken for collision resistance and must not be used for new signatures or certificates.
You can, but you should not store the result. A plain SHA hash is far too fast, which is exactly what an attacker wants when guessing billions of candidates. Password storage needs a deliberately slow, salted algorithm such as bcrypt, scrypt or Argon2. Use this for integrity checks, not credentials.
Almost always a text encoding difference. This hashes the UTF-8 bytes of your input, which is the near-universal convention. A tool that hashes UTF-16 code units, or that appends a trailing newline your input did not have, produces a different digest for the same visible text.