What your clipboard manager can see

Think about what has passed through your clipboard this week. A password pulled from a manager. A two-factor code. Part of a private message. An API key. A draft you rewrote three times.

Now consider that a clipboard manager sees all of it, by design. That is the feature. It is also why the tool deserves more scrutiny than most extensions you install.

The questions worth asking

1. Where does the history go?

This is the whole ballgame. There are broadly three models:

• Local only. History is written to the browser’s own storage on your machine. Nothing is transmitted. This is the safest default.
• Synced. History is uploaded so it can appear on your other devices. Now your clipboard exists on someone else’s server, and its safety depends on their security and their retention policy.
• Account-based. You sign in, which means the history is tied to your identity on top of being stored remotely.

Sync is a real convenience. It is also a real change in exposure, and it should be an explicit choice rather than a default you discover later.

2. What permissions does it request?

Chrome shows these at install. Two are worth understanding:

clipboardRead — lets the extension read the system clipboard. This sounds alarming, but a clipboard manager cannot function without it. It is the permission that catches copies made outside a web page, like from the address bar or the right-click menu.

Access to all sites — needed because the script that notices a copy has to run on the page where the copy happens. Narrower access would silently miss sites that were not on the list, and you would have no way of knowing which.

The important distinction is what the extension does with that access. Noticing a copy event is very different from reading page content. There is no way to tell them apart from the permission prompt, which is why the next question matters.

3. Is the behaviour written down?

A privacy policy that says “we may collect usage data to improve our services” is telling you something. So is one that names exactly what leaves the device and when.

Look for specifics: which storage API, whether there is a server at all, and what the exceptions are. Every tool has exceptions — favicon loading and optional AI features are common ones. A policy that admits to them is more trustworthy than one that claims a clean sweep.

4. Can you get your data out, and delete it?

Two directions matter. Export means you are not locked in. Clear and pause mean you stay in control of what gets captured in the first place.

Pause is the underrated one. Before you go rummaging through a password manager, switching capture off for a minute is a reasonable habit.

The awkward truth about passwords

No clipboard manager can reliably detect that the string you copied is a password. Some try to filter based on the source field, but copying from a password manager into a browser often does not carry that signal.

So assume anything you copy will be recorded, and plan around it:

• Use pause when handling credentials
• Delete individual items right after, if you forget to pause
• Set a history cap so old entries age out on their own

Where ClipView stands

For the record, since this post would be hollow without it:

• History, lists, templates and settings live in chrome.storage.local, on your machine
• There is no ClipView server, no account, and no analytics
• History does not sync between devices
• Two things do leave the device, both documented: source favicons load from Google’s public service (which sees the domain, never the copied text), and AI templates send one item’s text to Google — only if you add your own Gemini key and only when you run a template

That is the whole list. The full policy spells out each permission and why it is needed.