Two Google Calendar accounts on one Mac

Most people end up with two Google accounts by accident. A personal address that has been holding dentist appointments and flights since university, and a work address that arrived with a job. Then a third possibility appears, a second work domain from a client or a side project, and the number of places a commitment can hide goes up again.

The visible symptom is double booking. The underlying problem is not display. It is ownership. Every event in Google Calendar belongs to exactly one account, and that account decides who gets the reminder, whose free time the scheduler checks, and which inbox the invitation lands in. Any fix that only puts two grids on one screen leaves all of that untouched. Worth sorting out first: which of these things actually needs to be shared, and which only needs to be visible.

The three shapes this problem comes in

The right answer changes depending on which situation applies, and the three look identical from the outside.

The first is personal plus work. Both accounts belong to the same person, and the goal is that neither one schedules over the other. Details rarely need to cross the boundary. A dentist appointment does not need to appear at work by name, it only needs to block the slot.

The second is two work accounts. The person genuinely works in two organizations, and both sides send invitations that must be accepted, not just seen. Read only visibility fails here, because accepting an invitation from an account that cannot write is impossible.

The third is one account plus a shared calendar, a family calendar or a team calendar that someone else owns. This looks like a two account problem and is not one. It is a single calendar with a sharing permission attached, and it is solved entirely inside the sharing settings of whoever owns it.

Getting this wrong is the most common cause of an over engineered setup. People who only needed the first case build the machinery for the second, then wonder why work colleagues can see the name of a medical appointment.

What Google Calendar will not do

There is no merge function. Two Google accounts stay two accounts, and no setting inside either one collapses them into a single identity.

Several operations are also browser only, which matters because it constrains where the setup work can happen. Creating a new calendar is one. Subscribing to someone else's calendar is another, and Google states this directly: subscribing to a new calendar requires a computer web browser, and it cannot be done in the Calendar app for Android, iPhone, or iPad. Once the subscription exists, the calendar does show up in the mobile app.

There is also no desktop version to install. The official position on that is short.

Tip: You can’t download and install Calendar on your computer, but you can use it offline. Source: support.google.com

That matters for a two account setup because it rules out the obvious approach. Having both accounts open at once means either two browser windows signed into different accounts, or a third party client that holds both. There is no first party desktop app to point at the problem.

One more limit worth knowing before building anything elaborate: Google warns that subscribing to more than 400 calendars can cause performance problems when browsing calendars. Almost nobody hits this deliberately, but people who subscribe to every team calendar in a large organization can.

Sharing, and what each permission level really grants

Sharing one account's calendar with the other is the route most people should take, and the choice that matters is the permission level. Google offers five, and the gap between the second and the third is where nearly all the regret lives.

Permission	What the other account can do
See only free/busy (hide details)	Find out when the calendar is busy. No event or task names, no details
See event details	Find all details, including names, times, places, and descriptions
Make changes (see private events as free/busy)	Edit non private events. Private events show as busy blocks with no details, or not at all if marked free
Make changes and see event details	Edit events, and see who else the calendar is shared with
Make changes and manage sharing	Full control of events and tasks with a start and end time, plus the ability to share the calendar onward

For personal plus work, the first level is usually correct. It stops double booking and reveals nothing. For two genuine work accounts, the fourth is usually correct, because accepting and editing has to be possible. The fifth hands over the ability to reshare, which is rarely what anyone intends when they are just trying to see their own two calendars.

The direction also has to be chosen deliberately. Sharing is one way per calendar. Sharing personal with work does not share work with personal, and setting up only one direction is why half the fix appears to work and half does not.

The read only route and its trade off

There is a second way to see one account inside another, or inside any application: the secret address in iCal format, found under the calendar's settings in the Integrate calendar section. Pasted into another calendar application, it produces a view only copy.

The trade off is exactly what the name says. View only means no accepting invitations, no editing, no dragging an event to a new time. It also means the address itself is a credential. Anyone holding it can read the calendar without being logged in as anyone, which is why Google's own instruction is to keep it private and to press Reset if it ever leaks.

There is a place where this route is genuinely the right one. A calendar that will never be edited from the second account, a shared team schedule or a public timetable, does not need write access, and a read only feed avoids granting an account permissions it does not need. For a personal calendar that gets edited constantly, it creates a copy that goes stale in ways that are hard to notice.

Two browser windows, and why the numbering bites

Before any of that, most people try the free option: sign both accounts into the browser and switch between them. This works, and it has one failure mode worth naming.

Google gives each signed in account a position, and the calendar for the second account is reached at a URL that carries that position number. The number is assigned by sign in order, not by address, so it changes when an account is signed out and back in, or when a third account joins. Every bookmark built on the old number then opens the wrong account, silently, because both pages look the same until an event is created in the wrong place.

Separate browser profiles avoid this. One profile signed into one account gives each account its own window, its own cookies, and its own bookmark that always resolves to the same calendar. The cost is that the two calendars can never appear in the same grid, so double booking is still caught by the person rather than by the software.

There is a second cost specific to this route. Offline access is not available across all browsers, so a second profile running Firefox or Safari behaves differently from one running Chrome, and the difference only shows up on a train.

Where the browser route holds up well is a short term arrangement, a contract that ends in three months, or an account that gets checked twice a week rather than hourly. Where it stops holding up is when both accounts receive invitations daily, because the switching cost is paid every single time.

Putting both accounts in one client

The remaining route is a desktop calendar that signs into both accounts and shows them in one grid. Google supports this explicitly through Sign in with Google, which grants view and edit rather than the read only view a subscribed link gives.

On a Mac the built in Calendar app does this from Calendar then Add Account, and Apple notes that each account added is listed separately in the sidebar. That separation is the point. Events keep their owning account, colours can differ per calendar, and creating an event still requires picking which calendar it goes in.

Two things to check after connecting a second account. First, which calendars under that account are actually enabled, since an account can carry a dozen calendars and the client may show only some. Second, the default calendar for new events, which is the setting that quietly files work meetings into a personal calendar for months. The Features page covers what a Mac calendar can show across accounts at once, and the Guide walks through the setup order.

What no arrangement fixes

Some of this problem is structural, and it is better to know the residue in advance than to keep adjusting settings looking for it.

Invitations arrive at the address they were sent to. If a client emails the personal address, the event lands in the personal account, no matter how thoroughly the two are shared. The fix is not technical. It is telling people which address to use, and setting up mail forwarding so the invitation is at least seen.

Availability checks only look at what the signed in account can see. When someone outside proposes a time, they are checking the free/busy of the account they addressed. Sharing free/busy from the other account into that one is what closes the gap, and it only works in the direction it was set up.

Notifications arrive per account. An event shared across two accounts can produce two reminders on the same phone, and the cure is to turn off notifications on the borrowed copy rather than on the original.

Time zone is also an account level setting rather than a global one. Each account carries its own primary time zone in its general settings, and a work account configured by an employer in another country will render the same shared event at a different position in the grid. The events themselves are stored correctly, so nothing is lost, but two accounts with mismatched time zones make a shared calendar look wrong in a way that no amount of resharing corrects. Checking both settings takes a minute and removes an entire category of confusion.

Offline behaviour is narrower than most people assume. Offline access works in Chrome, and Google states that offline access and accessibility tools are not supported in Firefox, Safari, or Microsoft Edge. Offline, the calendar shows the last four weeks and anything in the future, and creating or editing events is not possible. For anyone planning to run two accounts in two browser profiles, that is a real constraint on the second profile.

Start with the direction, not the tool

Decide which account is the one being looked at every morning, then share the other one into it at the lowest permission that actually solves the problem, usually free/busy for personal and full edit for a second job. Live with that for a week before adding any software, because the week reveals whether the remaining friction is seeing events or entering them. If it turns out to be entering them, the useful comparison is between calendar apps rather than between sharing settings, which is what Compared with other calendars sets out.