How TinyX encrypts your files (and why we literally can't read them)

Most file-sharing tools encrypt your data. Very few can say they cannot read it. The difference is not marketing — it is where the key lives.

If you landed here after reading Dropbox is encrypted. That is not zero-knowledge., this is the sequel: how TinyX actually encrypts files, and why that architecture means we literally cannot open them.

That client-side AES-256-GCM path is a Pro / Max feature. Free still covers outgoing shares with expiry and passwords — it is not the E2E default.

Encrypted storage is not the same as zero-knowledge

Plenty of platforms encrypt files on disk (AES-256 at rest) and protect the pipe with TLS. That is table stakes. It protects against a stolen hard drive. It does not mean the vendor cannot decrypt what they store.

If the provider holds a usable copy of the key — or can mint one from their key-management stack — they can open the file for previews, scanning, support, or a legal request. The word “encrypted” still applies. Zero-knowledge does not.

TinyX’s claim is narrower and harder: client-side AES-256-GCM. Encryption happens in your browser before upload. The decryption key never touches TinyX servers. We store ciphertext we cannot open.

How the upload path works

Here is the practical flow, without the theater:

1. Key stays on the client. Your browser derives / holds the material needed to encrypt. That key is not sent to TinyX as a usable secret.
2. AES-256-GCM in the browser. Files are encrypted with the Web Crypto API before they leave the device. GCM gives confidentiality plus authentication — tampered ciphertext fails decryption instead of silently corrupting.
3. Ciphertext only on our side. What lands in storage is encrypted bytes plus the metadata needed to run the product (size, timing, link settings such as expiry and a password hash). Not plaintext. Not a recoverable master key.
4. Direct-to-object upload. Uploads go to object storage via short-lived, signed URLs. TinyX authorizes the write; the encrypted blob does not need to pass through an app server as readable content.

Large files can be handled in chunks so a flaky connection does not force a full restart. Resume still produces consistent ciphertext for completed chunks — the important part for zero-knowledge is unchanged: we never need the plaintext to store or serve the file.

What we can hand over — and what we cannot

When a link is live, TinyX holds:

• Encrypted file bytes
• Operational metadata (size, created time, expiry / download limits, password hash if you set one)

We do not hold a key that turns those bytes back into your document, gallery, or contract.

So if someone asks us for “the file,” the honest answer is: we can produce ciphertext and metadata. We cannot produce a readable copy, because the architecture does not give us one. That is not a support policy dressed up as security. It is a hard limit.

Expiry matches the same honesty: when a link dies, the content is gone — not soft-deleted into a forever archive, and not redirected to a sales page. Dead means dead.

What Free includes vs Pro+

Live pricing is the source of truth. Soft close, aligned with the cards today:

• Free: outgoing file share with expiry and passwords (caps: 150MB per file / 10GB storage). Upload drops and end-to-end encryption are not on Free — both are crossed out on the Free column.
• Pro ($9) / Max ($29): higher caps (Pro 1GB/100GB; Max 5GB/300GB), upload drops, and end-to-end encryption / zero-knowledge file crypto as Product documents on features.

If you need client-side encryption and inbound client uploads, start on Pro+. If you need controlled outgoing shares that expire and lock behind a password, Free still earns its keep.

FAQ

Can TinyX staff read my encrypted files? No. Staff with full storage access still see ciphertext. There is no master key on our side to “just decrypt it.”

What if I forget the password / lose the key material? Then the file cannot be recovered by us. Zero-knowledge without key escrow means forgotten secrets are gone. That is the trade-off.

Is “AES-256” alone enough to trust a vendor? No. Ask who holds the key, whether encryption is client-side by default for the files you actually send, and whether the share link can die. Algorithm names without custody details are incomplete.

Where do upload drops fit? Upload drops (clients send files to you) start on Pro+. They still sit under the same client-side encryption model — Free simply does not include that product surface.

Bottom line

“We promise not to look” is a policy. TinyX is built so looking is not an option: AES-256-GCM in the browser, key never on our servers, ciphertext only in storage, expiry that actually purges.

See features for the product surface, or pricing to pick a tier. Try free on tinyx.co for expiry- and password-gated shares; move to Pro+ when you need E2E encryption and upload drops.