How your calendar gets into manyCalendars

Calendar products often use the word "connect" as if every connection were the same. They are not. An ICS subscription is a URL. A browser bridge reads a page you already opened. A one time file import is a snapshot. Optional Cloud Sync is another step again.

That difference matters for reliability and privacy, so here is the actual reading order used by manyCalendars.

What "connect a calendar" means here

Connecting a calendar to the Free extension does not mean handing manyCalendars your work password. The extension works inside your browser and can read only a source you choose. Your provider login and session cookies remain in that browser profile.

The result also stays local unless you turn on Cloud Sync. Cloud Sync is the optional route to the companion web calendar. It copies only selected calendar data to your signed in web account, with busy only details as the default. If you do not need web access, you can keep Cloud Sync off.

All source methods are read only. They do not create, edit, accept, decline, or delete events in Outlook, Google Calendar, Apple Calendar, or another provider.

1. The local browser bridge

The extension itself is the primary connection. It runs beside the calendar in Firefox, Chrome, or Edge and reads supported information already available to the signed in page. The bridge keeps source accounts in their original browser contexts, which is especially useful when several companies use separate identities.

A bridge still has boundaries. The calendar page must be open or available to the browser, the extension must be allowed to run, and the user must be authorized to view the source. A managed device can block extensions. A company can prohibit external use of calendar data. The bridge does not override either rule.

2. An ICS subscription feed

An ICS subscription is the least surprising connection when the provider offers one. The extension can read a normal https:// or webcal:// calendar feed from Apple, Google, Outlook, or another service that follows the iCalendar format.

Subscriptions and files are different:

• An ICS subscription can receive later changes when the extension checks the feed.
• An ICS file is a one time copy unless you import a new file later.

The feed owner controls what detail appears. The URL should be treated as sensitive because someone with the working link may be able to read the exposed calendar data.

3. A calendar tab you choose

For selected Outlook Web and Google Calendar sources, you can choose the open tab that belongs to that calendar. The extension remembers the correct browser session for later refreshes. In Firefox, this can include the correct Multi Account Container. In Chrome or Edge, it can be a separate browser profile.

Selecting a tab is important when two accounts use the same provider. The calendar name alone is not enough to identify which signed in context owns the events.

4. Passive page data reading

Some calendar pages send structured event data to their own open interface. When a supported page does that, the extension can read a copy of the information already delivered to the page. It does not replay the request, replace the response, or send a command back to the provider.

This is a fallback because provider pages change. A field can be renamed, the response shape can change, or the browser can suspend the tab. A source health label should make those failures visible.

5. The visible week or month check

If the normal read cannot confirm the calendar, the extension can inspect the week or month view that is already visible to the user. It may need to move through the provider interface or open hidden items to verify what is on screen.

This method is experimental and intentionally cautious. Calendar pages can show only the current viewport, collapse events behind a count, or reuse page elements while you scroll. If manyCalendars cannot verify the full date range, it protects saved dates outside the confirmed view instead of assuming those events were deleted.

6. File import and manual calendars

Two methods do not refresh by themselves:

• ICS file import. Open or drop an .ics file. It is parsed locally on the device.
• Manual calendar. Create a local source and enter the event yourself when no feed, file, or supported tab is available.

These methods are deliberately plain. They are useful for a school schedule, a one off appointment, or a provider that has no ongoing connection.

How the methods compare

Why no method gets to pretend it is perfect

A feed can lag. A browser session can expire. A calendar page can change. A partial month view can hide events. The safe response is not to label every guess as a successful sync.

manyCalendars tracks the source and its last read state. When a source is incomplete, it can require a visible check. When a date range was not fully verified, events outside the confirmed range stay protected. The original provider calendar remains the source of truth.

Privacy changes when you choose web access

Local extension use and companion web access have different data boundaries:

• Extension only. Calendar information remains on that device.
• Cloud Sync on. Selected calendar copies are sent to your private web calendar so another device can display them.

Provider passwords and raw session cookies are not part of Cloud Sync. You can also choose busy only data and use Privacy Mode to mask names on the screen. If a company does not permit any external copy, do not enable Cloud Sync for that source.

Technical details reviewed August 25, 2026. Provider interfaces and browser APIs change, so the product source health indicator remains the best check for a specific calendar.