Comparing Calendar Data Formats: ICS, CalDAV, and JSON

Why calendar formats matter

When you subscribe to a calendar feed, export events, or connect a calendar tool to your account, data moves between systems in a specific format. The format determines what information survives the transfer, how fresh the data is, and what tools can read it.

For multi-client professionals who need to aggregate calendars from different providers, understanding these formats helps you make better decisions about how to connect your calendars and what to expect from each method.

ICS: The universal calendar standard

ICS (iCalendar) is the de facto standard for calendar data interchange. Defined in RFC 5545, it is a plain-text format that has been around since 1998. Every major calendar platform supports it: Google Calendar, Outlook, Apple Calendar, and virtually every scheduling tool.

What it looks like: An ICS file is human-readable text. Events are wrapped in VEVENT blocks with properties like DTSTART (start time), DTEND (end time), SUMMARY (title), and DESCRIPTION (body text). Recurring events use RRULE patterns.

Strengths: Universal support. Any calendar app can import an ICS file. ICS feeds (URLs that serve ICS data) allow one-way subscription: your calendar fetches the feed periodically and displays events from it. No API keys, no OAuth, no special configuration.

Limitations: ICS feeds are typically read-only and poll-based. Your calendar checks the feed on a schedule (often every 12 to 24 hours for Google Calendar). This means changes can take hours to appear. There is no push notification, no real-time update, no way to write back to the source.

How manyCalendars uses ICS: manyCalendars can subscribe to any ICS feed URL and parse it locally. Because manyCalendars runs in your browser and refreshes more frequently than cloud calendar apps, you get fresher data from ICS feeds than you would from a native Google Calendar subscription.

CalDAV: The sync protocol

CalDAV (Calendaring Extensions to WebDAV) is not really a data format. It is a protocol built on top of ICS. Where ICS gives you the event data, CalDAV gives you a way to create, read, update, and delete events on a remote server. Think of ICS as the language and CalDAV as the conversation.

How it works: A CalDAV client connects to a server, authenticates, and can then perform full CRUD operations on calendar events. The events themselves are still stored as ICS data on the server. CalDAV just provides the transport and synchronization layer.

Who uses it: Apple Calendar (iCloud) uses CalDAV as its primary sync protocol. Many open-source calendar servers (Radicale, Baikal, Nextcloud) expose CalDAV interfaces. Google Calendar supports CalDAV but primarily pushes its own API.

Strengths: Two-way sync. Real-time or near-real-time updates. Standardized protocol that works across implementations. Good for situations where you need to both read and write events.

Limitations: Requires authentication credentials. More complex to implement than simple ICS feed consumption. Corporate environments often restrict CalDAV access to approved clients only. As a contractor, you typically cannot set up a CalDAV connection to a client's calendar server without IT involvement.

How manyCalendars relates to CalDAV: manyCalendars does not use CalDAV directly. CalDAV requires server-to-server authentication, which conflicts with manyCalendars's local-first, no-credentials approach. Instead, manyCalendars achieves similar visibility through Tab Sync (reading what your browser already displays) and ICS feeds (no authentication required beyond the feed URL).

JSON: The API response format

JSON is not a calendar standard. It is a general-purpose data format that happens to be what most calendar APIs return when you query them programmatically. Google Calendar API, Microsoft Graph API, and nearly every modern scheduling tool returns event data as JSON.

What it looks like: Events come back as JSON objects with fields like "start", "end", "summary", "attendees". The structure varies by provider. Google and Microsoft use different field names, nesting patterns, and date formats.

Strengths: Rich data. JSON responses from calendar APIs include information that ICS often omits: attendee RSVP status, conference call links, attachment metadata, calendar-specific settings. It is also easy to parse programmatically and integrates well with web applications.

Limitations: No standardization across providers. Every API has its own schema. Accessing calendar APIs requires OAuth tokens, which means IT admin visibility and approval workflows. JSON is the format of cloud aggregators that need full API access to function.

How manyCalendars handles JSON: When manyCalendars syncs a calendar tab, it reads the rendered DOM and extracts event data into its own internal JSON structure. This is not the same as calling a calendar API. manyCalendars reads what you already have permission to see in your browser, converts it to a normalized internal format, and merges it with events from other sources.

ICS as the lingua franca

Despite its age and limitations, ICS remains the most practical format for calendar interoperability. It works across providers without requiring API access. It does not trigger IT notifications. It carries enough event data for scheduling decisions (times, titles, recurrence) even if it lacks the richer metadata that APIs provide.

For contractors and consultants managing multiple client calendars, ICS feeds represent the lowest-friction path to aggregation. Where ICS feeds are unavailable (because the corporate tenant disabled them), Tab Sync fills the gap by reading the already-rendered calendar view.

manyCalendars is built on this pragmatic approach: use the most accessible data source for each calendar, normalize everything into a single view, and give you the conflict detection and availability tools you need. No OAuth tokens. No admin approvals. No format wars. Just your schedule, unified.

Curious how this works in practice? Install manyCalendars and connect your first calendar in under a minute. The formats handle themselves.