Your clipboard is a security hole. Here's what to check.

Here's an uncomfortable fact about most clipboard managers: everything you copy, including passwords, 2FA codes and API keys, gets written to a database on your disk in plaintext. If someone has access to your machine, a backup or the sync server, they can read it.

The convenience is real. So is the exposure. This is a short guide to what to check before you trust a clipboard manager with your day.

What "stored in plaintext" actually means

When you copy a password, a typical clipboard manager appends it to a local history file, often an unencrypted SQLite database. That file is:

• Readable by any process running as you.
• Included in unencrypted backups.
• Sometimes synced to a cloud you don't control, in the clear.

You can verify this yourself for any tool you use:

# Find the history database (paths vary by app)
find ~ -name "*.sqlite" -path "*clipboard*" 2>/dev/null

# If you can read secrets out of it in plaintext, so can anything else
sqlite3 <path> "select * from history limit 20;"

If your copied secrets show up there as readable text, that's the problem in one command.

A checklist before you trust one

If a tool can't answer the first two with "yes," assume everything you've ever copied is readable somewhere.

How end-to-end encryption changes the picture

End-to-end encryption means clips are encrypted on your device before they're stored or synced, and only your devices hold the keys. The server stores ciphertext it can't read. Without your keys, a stolen local or cloud database is useless.

That's the model Clypy uses. On top of it:

• App exclusions keep password managers and banking apps from being captured at all.
• Type-aware history flags secrets and can auto-expire them on a timer you set.
• Nothing readable server-side. Sync moves ciphertext only.

The safest clip is the one that was never stored in the clear. Read more about how Clypy handles security.