share / privacy

Privacy proof

Content is encrypted in your browser before upload. The decryption key lives only in the URL fragment after #k=. Browsers never send fragments to the server, so the operator cannot decrypt your media or destinations even with full database and disk access.

What the server stores

  • AES-256-GCM ciphertext (magic header SHRE1 + IV + sealed bytes)
  • Metadata: link code, content type, filename, size, view counts, expiry
  • Optional password hash (separate from the content key)
  • Optional Discord preview image and title/description — these stay plaintext so embeds work

What the server never has

  • The AES content key (only in #k=…)
  • Plaintext of shared text, files, or short-link destinations
  • Ability to regenerate a lost full URL if the fragment was not saved

Expiry wipe

When a link expires (time, view limit, or disable), ciphertext files are deleted from disk. Cleanup also runs hourly. After purge, even the sealed bytes are gone.

How to verify yourself

  1. Create a share, then open DevTools → Network. Confirm request URLs have no #k= fragment.
  2. Open the share URL without the fragment: you get “Encryption key missing”, not readable content.
  3. Use the demo below: encrypt locally, inspect the ciphertext prefix, and confirm decrypt fails without the key.

Live demo (runs only in your browser)

Nothing from this demo is uploaded. Encrypt → see ciphertext → prove a wrong key fails.

Admins can list their own links and manage accounts, but cannot open other users’ content without the URL fragment key those users hold.