Every link password now stops at your browser

Put a password on a TinyX link and that password does a job. On an encrypted link it is the key — your browser uses it to encrypt the file before anything is uploaded. On an ordinary link it's the thing that decides who gets in.

From this release, in both cases, it doesn't travel any further than the browser you typed it into.

What changed

Your browser now does two things with the password instead of one.

Where there's a file to encrypt, it derives the encryption key, as before. And in every case it separately derives a short access code — and that is the only thing sent to us when someone opens the link. The code is enough for us to say "yes, this person knows the password" and useless for anything else. You cannot work backwards from it.

So what we hold is a link, maybe an encrypted file, and a code proving somebody knew the password. Not the password.

Previously only encrypted links worked this way. Having two standards for the same box was the kind of inconsistency that eventually catches someone out, so now there's one.

One standard, one button

Because the password can be the key, a weak one is the weak point — and there's nothing we can do about that from our side, precisely because we don't have it. So every link-password field now has:

• A minimum standard. Fourteen characters, a little variety, and we'll turn away the few hundred

passwords that get tried first — including the ones with a 3 where an e should be.

• A Generate button. One click gives you something like cobalt-thistle-lantern-mesa-7Kq2mXv.

It's strong in a way a memorable password isn't, and it's meant to be copied rather than remembered.

Both appear when you create a link and when you change its password later, which previously had neither.

Worth saying plainly: we cannot recover it for you. That isn't a limitation we're apologising for. It's the thing you came here for.

Two costs, stated rather than buried

Password-protected links now need JavaScript. Turning a password into an access code has to happen in your browser. Links you made before this release are unaffected and still work without it.

Encrypted links made before this release can no longer be opened. The method changed, and files encrypted the old way can't be read with the new key. If you have one, upload the file again and share the new link. And if someone sends you an old one, the page tells them exactly that rather than insisting their password is wrong — being told you mistyped something when you didn't is a miserable way to spend five minutes.

If you set link passwords through our API, password is no longer accepted there; the API docs cover what to send instead.

Where this ends

One honest note, because this is the sort of claim that's easy to oversell.

The encryption and the access-code step both run in JavaScript that we serve to you. So this stops us reading files we are already holding; it cannot stop a future change to the code we ship. Every product built this way shares that limit, and not all of them write it down. Ours does — the security page says what we hold and where the protection stops, and the privacy policy matches it.

If that distinction matters to your work, encrypt the file yourself before you upload it and let us handle the delivery. For everything else: your password stays in your browser now, and that's a better place for it than ours.