"Encrypted" is an adjective, and adjectives are hard to check. A product page can say it about almost any arrangement of software and be defended on a technicality. The question underneath it is more useful and much more concrete: at each step between your fingers and a disk somewhere, who holds the key that would open this thing?
Following one entry through the system answers that question in a way a claim cannot. Here is the journey, with the steps named.
Step one: the key exists before the entry does
Before anything is typed, the app derives a key from your passphrase. This happens on your device, and it uses a deliberately slow function so that guessing passphrases is expensive rather than cheap. The output is split, and the split is the part worth understanding.
One half is the key that decrypts your calendar. It stays in the memory of the device you are holding. The other half is used to prove who you are when you sign in, and the server stores only a hash of it. The important property is not that the passphrase is secret. It is that the two halves are not interchangeable: the half the server holds cannot be used to reconstruct the half it does not, so a complete copy of the server's database is not a way in.
Step two: the entry is sealed before it moves
You type a title, a time and a location. The app seals that record with a key derived for it specifically, then sends the result.
What leaves the device is a blob, an initialisation value, and some identifiers. There is no title in the request, no location, and no field the server could read even if it wanted to. If you open the network panel in your browser while saving an event, this is visible: the request body contains no words you typed.
The key for that record is derived rather than stored, which is why there is no list of per-event keys sitting anywhere to be stolen. It is computed from the calendar's key and an identifier, used, and discarded.
Step three: the server stores bytes it cannot open
The server writes the blob into a row, alongside a timestamp and an identifier. It can move that row from one machine to another, back it up, replicate it, and serve it back to you. At no point does it hold anything that turns the blob back into a dentist appointment, because the material that would do that never arrived.
This is the point where a product's claim generally becomes checkable, and it is worth saying that the answer is about arrivals, not intentions. A server cannot decrypt what it was never sent the means to decrypt. That is a property of the data flow rather than a promise about conduct, which is why it survives a change of management, a subpoena, or a mistake.
Step four: sharing, which is where the keys get interesting
A shared calendar has one key, and each member holds a copy of it wrapped for them alone. Adding somebody means wrapping that key in a form only they can unwrap; it does not mean sending them everybody else's credentials or giving the server a way to hand the key out.
The wrapping is why an invitation works the way it does. The material that unwraps the calendar key is generated on the device of whoever sends the invitation and placed in the part of a link that browsers never transmit — the fragment, after the #. It reaches the recipient's device without passing through the server in a readable form, which is also why an invitation cannot be accepted on somebody else's behalf.
The questions worth asking about any product
Adjectives are unfalsifiable. These are not.
- Is there a password reset? If a provider can restore your access, the provider holds a key to your data. That is not necessarily wrong, but it is the answer to the question, and it should be stated rather than discovered.
- Is there an administrator view that decrypts anything? Support tooling that can read a customer's data is a way in, whether or not it is used.
- What does the client actually send? This one you can check yourself, in the browser's network panel, in about a minute.
- Which parts are not end-to-end encrypted? There usually are some. A sync feed, a search index, an email digest. The honest products name them, because the alternative is a reader assuming there are none.
The limit that applies to every web application
One caveat belongs at the end of any explanation like this, including one written by the people who built the thing. The code that does the encrypting is delivered to your browser by the operator of the service. If the operator served you different code, the cryptography would be theatre, and nothing you can inspect from the outside would tell you.
That is true here, and it is true of every web application that has ever claimed end-to-end encryption. The complete answer is a client you build yourself from published source, which is beyond what most households want to do. The practical answer is that the properties above — what is sent, what can be reset, what is not encrypted — are the ones you can check, and they are the ones that decide whether the claim means anything.
More on how this particular app does it is in the answers to the usual questions.