How to share a calendar without oversharing

The steps for sharing a calendar take about two minutes. The part that causes trouble later is the decision made before those two minutes: how much of the calendar the other person gets to see. Share the wrong thing and a dentist appointment, a job interview, or a family matter shows up in a colleague's sidebar, and there is no way to pull it back once it has been seen.

What follows is the full shape of calendar sharing on a Mac: the four different mechanisms that all get called sharing, the permission levels inside each one, and the three problems that appear reliably after a share is set up.

Sharing is three decisions stacked together

The settings screens look complicated because three separate questions are answered in three different places.

The first question is who. Sharing can be aimed at a specific email address, or opened to anyone holding a URL. These behave completely differently when the relationship ends: an address can be removed, a URL that has been forwarded cannot be recalled.

The second question is how much. A calendar can expose full event details, including titles, locations, notes, and attendees, or it can expose nothing but whether a block of time is taken. The second option exists as a distinct thing in the underlying standard, not as a lesser version of the first.

The third question is whether the other person can edit. Read access, write access, and the right to manage sharing for other people are three different levels, and the last one is handed out far more often than it needs to be.

Answering all three before opening any settings screen turns a confusing menu into one or two clicks. Most of the regret around calendar sharing comes from answering only the first question and accepting whatever defaults the app supplied for the other two.

The four shapes of sharing

Product names vary, but there are only four mechanisms underneath.

Shape	Who gets in	What they see	Good for	The catch
Named person	An email address	Details or busy blocks, by permission	Colleagues, family, anything ongoing	Requires an account on their side
Free and busy	Anyone asking	Whether time is taken, nothing else	Scheduling with people outside the company	Carries no context at all
Public or feed URL	Anyone with the link	A read only copy	Event schedules, opening hours	Forwarding cannot be undone
Single invitation	Per event	That one event	One off meetings	No access to the rest of the calendar

The second row is the one most people never find, even though it is what they actually wanted. Publishing availability without publishing content is a first class concept in the iCalendar specification, which defines a separate component for exactly this purpose.

Purpose: Provide a grouping of component properties that describe either a request for free/busy time, describe a response to a request for free/busy time, or describe a published set of busy time. Source: rfc-editor.org

That distinction has a practical consequence. When the goal is to let someone find an open slot, the correct move is not to share the calendar and hope they ignore the titles. It is to expose availability and nothing else, which is a supported configuration in every major calendar service rather than a workaround.

Sharing a Google calendar with a named person

In Google Calendar, sharing lives per calendar rather than per account. Hover the calendar name in the left sidebar, open its settings and sharing screen, and find the section for sharing with specific people or groups. Add an address there and pick a level.

There are four levels, in increasing order of exposure:

• See only free and busy, with details hidden
• See all event details, including titles, locations, descriptions, and guests
• Make changes to events
• Make changes and manage sharing, which includes granting access to other people

The fourth level is the one to be careful with. It lets the recipient hand access to anyone else, and cleaning that up after someone changes roles or leaves means auditing a list that has grown without anyone watching. Unless the person is genuinely acting as a delegate, the third level is the practical ceiling.

Once added, the recipient gets an email and the calendar appears in their list after they accept. Reflection is not instant, because it depends on how often their client syncs. When someone reports that a shared calendar is not visible, the cause is almost never the permission: the calendar has been added, but its visibility checkbox is switched off on their side. Check that before changing anything in the sharing screen.

One more constraint worth knowing before troubleshooting: on managed workspace accounts, administrators can block sharing with addresses outside the organization. If the option refuses to stick, it is policy rather than permission, and repeating the steps will not help. The current interface is documented in Google Calendar Help.

Public links, feed URLs, and the secret address

To reach people regardless of which calendar service they use, sharing happens by URL. Three URLs with very different properties sit in the same settings panel, which is where most of the confusion starts.

The public URL appears once a calendar is made public, and it opens in a browser. The public iCal address is a feed meant to be subscribed to inside another calendar app. The private or secret iCal address is a feed that works without making the calendar public at all, because the URL itself is the credential.

That last one deserves care. Anyone who receives a forward of it has the same access as the original recipient, permanently. Revoking it is not a matter of removing a person, because there is no person on record. It requires resetting the address, which breaks the subscription for everyone who was using it, including the people who were supposed to have it.

Subscribed feeds are also read only and slow. Refresh intervals are decided by the subscribing client, and a change made in the morning may not appear on the other side for hours. That makes feeds a poor fit for anything that changes on the day. They work well for fixed schedules: term dates, opening hours, release calendars, a season of fixtures.

iCloud and the built in Mac calendar

The same split applies on the Apple side. An iCloud calendar can be shared with named people, who accept with an Apple ID and can be given edit rights or left read only. Changes made by an invited editor generate notifications back to the owner, which suits a household or a small team where everyone is expected to add things.

The other route is a public calendar, which produces a read only link that works without an Apple ID. Same trade as the feed URL above: no account needed on their side, no way to take it back except by turning the link off for everyone.

When a Google account is connected to the Mac calendar app, visibility on the Mac and sharing on the web are separate settings that do not always agree immediately. Revoking access on the web can leave a stale calendar visible locally until the next sync completes. Account setup and the location of each of these controls is documented in Apple Support.

Auditing what is already shared

Sharing accumulates. Access granted for one project stays live for years, because nothing prompts a review when the project ends. A quick audit is worth doing before adding anything new, and it takes a few minutes.

Open each calendar's sharing settings in turn and read the list of people rather than skimming it. Three things are worth acting on. Anyone who has left the organisation or the project should be removed outright. Anyone holding the manage sharing level who is not acting as a delegate should be dropped one level. Any calendar that is public should be checked against whether it still needs to be, because public status is easy to enable during a one off and easy to forget afterwards.

Feed URLs need separate attention, since they do not appear as names in any list. If a secret address was ever pasted into a group chat or an email thread, treat it as circulated and reset it. The cost is that current subscribers have to be sent the new address, which is a small price relative to a link that cannot be revoked any other way.

Three things that break after the share

Sharing is quick. The cleanup afterwards follows a predictable pattern.

The first is duplicated events. Subscribing to a colleague's calendar while also being an invited guest on the same meetings produces two entries for one meeting. Nothing is broken: there are genuinely two sources describing the same block of time. The fix is to hide one of them, either the subscribed calendar or the invitation feed, rather than to reconfigure the share.

The second is notifications. Alerts on a shared calendar are controlled by the person viewing it, not by the person who shared it. A phone buzzing about someone else's dentist appointment is fixed locally by turning notifications off for that specific calendar. The mirror image also holds: when a recipient says alerts are not arriving, the owner cannot fix it from their end.

The third is colour. Calendar colours are a viewer side setting, so the colour scheme carefully chosen by the owner is not what the other person sees. Teams that use colour to encode meaning should encode it in separate calendars instead, because calendar membership survives the trip and colour does not.

Split the calendars before setting permissions

Nearly every oversharing incident traces back to a single calendar holding everything. When work, personal, medical, and family events live in one place, the only available choices are exposing all of it or exposing none of it.

A single account can hold many calendars, and that is the lever. Separate calendars for work, internal meetings, personal, and family means sharing can be set on one of them and the rest are out of scope by construction. Full details can then be shared without hesitation, because the calendar being shared contains only the events intended for that audience.

Marking individual events private is the alternative, and it fails for a mundane reason: it depends on remembering, every time, forever. One missed event undoes the whole arrangement. Structure holds where discipline does not.

The cost of splitting is that toggling visibility becomes tedious, which is why switching groups of calendars in one action is a feature paid Mac calendars compete on. What that looks like in practice is covered in Features, and a side by side of which apps handle it is in Compared with other calendars.

What to change first

Sharing only transmits what is already in the calendar, so the two failures that survive every permission change are events that were never entered and travel that was never scheduled. Both make a shared calendar actively misleading: an unentered commitment reads as free time to everyone looking, and travel between two locations reads as a gap someone else will book. Those are the failures Caltimate is built around, and the reasoning behind treating travel as a property of the day rather than of one event is in Travel time. Split the calendars first, share the work one at the level below the highest, then spend a week noting every commitment that never made it in.