Google Docs, Notion, Microsoft 365, and Confluence all encrypt your documents at rest and in transit. None of them are end-to-end encrypted, meaning the provider can read the contents on their servers, and this isn't an oversight. Real-time collaborative editing and end-to-end encryption are pulling in opposite directions, and most of the industry has, so far, picked collaboration.
"Encrypted" on a cloud storage or document platform's marketing page almost always means encrypted at rest, on the provider's disks, and in transit, over TLS while it travels between your browser and their servers. Both are real protections against an attacker who steals a hard drive or intercepts network traffic. Neither stops the provider itself from reading the document, because the provider holds the decryption keys. That's a deliberate architectural choice, not a corner cut, and it exists because of how collaborative editing actually works.
The technical conflict
Real-time collaborative editing, the kind where you can see a coworker's cursor and their keystrokes appear in your document within milliseconds, relies on the server actively participating in resolving what happens when two people type in the same place at the same time. The dominant approaches are operational transformation and CRDTs (conflict-free replicated data types), and both were designed with a server, or at minimum a shared relay, that processes the actual edit operations to merge them correctly.
