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. A stolen database — local or cloud — is useless without your keys.

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, ever — sync moves ciphertext only.

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