Privacy and security
Your clipboard carries whatever you were about to paste — passwords mid-transit, addresses, half-written messages, tokens. This page says exactly what happens to it, in enough detail that you can check.
What happens to an item
Four steps, in order. The first happens once; the rest on every copy.
- 1
A key is derived from your passphrase — once, when you set sync up on a device
On the device, using PBKDF2 at 600,000 rounds, then held in that device's Keychain. It is not re-derived on every copy. The passphrase is yours; the key that comes out of it never leaves your devices and is never sent to us.
- 2
The item is sealed with AES-GCM
Encryption happens on the device that captured the item, before anything is uploaded. AES-GCM is authenticated, so a modified blob fails to open rather than decrypting to something wrong.
- 3
The ciphertext is uploaded
What reaches the server is a blob it has no key for, alongside the small amount of metadata sync needs: which account, when, and how far through the feed it sits.
- 4
Your other devices open it
They derive the same key from the same passphrase and decrypt locally. Search runs on the device for the same reason — the server has nothing it could index.
What our servers can see
Encrypted does not mean invisible. Syncing requires some metadata, and it is more honest to list it than to imply the server holds nothing at all.
The encrypted item
An AES-GCM blob. Stored rows are indistinguishable from random.
Which account it belongs to
Your UniAuth user identity, so your devices can find your items.
When it was added, and its position in the feed
Timestamps and a sync cursor, so devices know what is new.
Roughly how large it was
Ciphertext has a length. We do not pretend otherwise.
What you copied
The contents are encrypted before upload. There is no key on our side.
Your passphrase, or any key derived from it
Derived on the device and never transmitted.
Anything searchable
There is no index, because there is nothing to index.
Amber marks what the server holds. Green marks what it does not.
What is held back before it is recorded
Encrypting everything does not help if the wrong things are captured in the first place. Three kinds of content are held back from the moment you install UniClip. Two of them are yours to change; one is not.
Content an app marks confidential — always
Anything published as org.nspasteboard.ConcealedType is refused from the type alone, before its value is read. It is not encrypted and stored — it is never taken. This one is not a setting, and that is deliberate: the marker is another application asking not to be recorded, so you are not the only party to the decision. There is a practical reason too. Refusing it without reading it is the whole point, and a switch would mean loading concealed values into the app in order to throw them away.
Anything copied out of a password manager — unless you say otherwise
Twelve are excluded when you install it, from 1Password and Bitwarden to KeePassXC and the macOS Keychain. Copying a password out of one does not create an item. You can add other apps to that list, and you can remove any of the ones that came with it — including all of them. Removing one is remembered; it does not quietly come back.
Anything shaped like a credential — unless you turn it off
API keys, JWTs, private keys and payment card numbers are recognised, kept on the device that copied them, shown masked in the list, and never uploaded. Card numbers are Luhn-checked, so an ordinary sixteen-digit number is not mistaken for one. Turn detection off and none of that happens: matching items are recorded and synced like anything else.
Turning something off is a decision, not a confession
There are ordinary reasons. Test credentials that reach nothing real. A key you are moving between machines on purpose. Or simply preferring a complete history because it is end-to-end encrypted, that being the entire point. UniClip does not ask twice, does not put a banner up, and does not switch itself back on at the next update.
What does not change is the encryption. Anything you let through is sealed with your key on the device before upload, so a synced API key is ciphertext to us in exactly the way a synced street address is. These settings decide what gets recorded; they do not weaken what protects it.
This page, in the app
The privacy pane on the Mac is the whole of the section above, made checkable: the absolute stated at the top, the detection switch, and every shipped app in the excluded list with a remove control beside it.
The cost of the guarantee
A design where we cannot read your data is also a design where we cannot rescue it. That cuts both ways, and you should know which way before you rely on it.
Nobody here can recover your history for you
The key exists only on your devices, derived from your passphrase. There is no copy on our side to fall back on, no support process that can decrypt your items, and no reset that returns your history. That is precisely what makes the claim on this page worth anything — but it means the passphrase is yours to keep safe.
Deleting your data
The app can delete individual items, and it can delete your sync account outright, which removes the stored ciphertext along with it. Your UniAuth account is separate and is managed from your UniAuth account settings.
Signing in
UniClip signs in with your UniAuth account over OpenID Connect, using an authorization code flow with PKCE. It never handles your UniAuth password.
Two separate secrets are at work here, and it is worth keeping them apart. Signing in proves who you are, so the sync service knows whose items are whose. Your passphrase makes the items readable, and the service never sees it. Someone who compromised your sign-in would find encrypted blobs; someone with the passphrase alone would have nothing to apply it to.