hidetext.sh

How it works

hidetext.sh is end-to-end encrypted: your content is scrambled on your own device before it ever reaches us, and we never receive the key needed to unscramble it. This page explains exactly how that works — so you don't have to take "we can't read it" on faith.

The problem with normal paste tools

Most text- and file-sharing sites receive your content as plain data and store it in their database. They canread it. Their staff can read it. Anyone who breaches them can read it. And many keep it long after you think it's gone. A promise not to look is only as good as the company making it.

We wanted a design where reading your content isn't something we choosenot to do — it's something we can't do.

The core idea: encrypt before it leaves your browser

Everything happens on your side first:

  1. You type text or pick a file.
  2. Your browser generates a random 256-bit key.
  3. The content is encrypted locally with NaCl secretbox (XSalsa20-Poly1305), using that key and a fresh random 24-byte nonce.
  4. Only the encrypted result — nonce plus ciphertext — is sent to our server. For files, the encrypted bytes go to storage; for text, the scrambled blob goes to the database.
  5. The key is placed into the link, in the part after the # — for example: https://hidetext.sh/abc123#‹key›
  6. You send that link to whoever should read it. Their browser pulls the encrypted blob from us, reads the key from the link, and decrypts everything locally.

Why the # is the whole trick

The fragment of a URL — everything after the # — is special: browsers never send it to the server.It stays on the client side by design, as part of the web's own specification.

That's where we put the key. So when someone opens a hidetext.sh link, their browser requests only the scrambled blob from us; the key rides along in the address bar but never reaches our servers. We store the locked box, the link carries the key, and the two only ever meet inside a browser.

What our server actually sees

For a normal paste or file, our server only ever holds:

  • the encrypted blob (nonce + ciphertext, or encrypted file bytes),
  • a random slug / ID,
  • the timing data it needs to function: when it was created, when it expires, and whether anyone is currently viewing it (for burn after read).

It never sees your plaintext, and it never sees the key.

Burn after read

If you enable burn after read, the link is deleted after it's viewed — but deliberately notthe instant the first request lands. The reader's tab sends a quiet heartbeat while the content is open, and it's deleted only once that heartbeat stops. This stops link previews, scanners, and chat-app crawlers from silently "reading" and destroying your paste before your actual recipient opens it. A scheduled job also sweeps anything past its expiry.

What this does and doesn't protect

Being straight about the limits matters more than sounding bulletproof.

It protects against:

  • us reading your content — we hold only scrambled data and no key;
  • our staff, or a database breach, exposing what you shared;
  • your content lingering forever — it expires or burns.

It does not protect against:

  • Anyone who has the link. The link is the secret. If you send it over an insecure channel, or the recipient forwards it, whoever holds it can read the content. Share links carefully, and use burn after read or short expiries for anything sensitive.
  • A compromised device.If your device or the recipient's has malware, or someone is looking over the screen, encryption can't help.
  • Trust in the code we serve. Because encryption runs in JavaScript your browser downloads from us, you are trusting that we serve honest code. This is inherent to every browser-based end-to-end-encrypted tool.
  • Metadata.We necessarily know that a paste exists, its size, and its timing (created, expiry, when it's opened). We do not know its contents.
  • A couple of narrow exceptions. A file's nameis stored in plain text (its contents stay encrypted), and the optional "Send to device" feature briefly transmits the key to us so another of your own devices can grab it — stored for at most 30 seconds, then deleted. Both are described in full in our Privacy Policy.

Third parties

The only outside requests your browser makes are a Cloudflare Turnstile CAPTCHA — and only if the paste's creator turned it on — plus a couple of small icons used for link previews, and, if you choose to use voice input, your browser's own speech-recognition service (see Privacy Policy). There are no analytics, trackers, or advertising scripts anywhere.