Combining two Gmail calendars into one view

Two Google accounts, two calendars, and a day that is only visible if both are open at once. That is the situation, and it usually gets worse rather than better, because the second account tends to be the one carrying the work meetings while the first one carries everything that makes the work possible.

There are three genuinely different ways to solve this, and they produce three different results. Picking the wrong one is the reason people end up with stale events, read only copies, or a calendar that shows the same meeting twice. What follows is what each method does, what it costs, and how to tell which one the situation actually needs.

What combining can mean

The word covers three outcomes that behave nothing alike.

Seeing both in one grid. The calendars stay separate and stay editable in their own accounts, but they render in the same window, in different colours. Nothing is copied. This is what almost everyone actually wants.

Merging into one calendar. The events from one account are copied into the other and the source is abandoned. This is a one time move, not a sync, and it is only correct when one account is genuinely being retired.

Subscribing to a copy. One account follows a feed published by the other. The events appear, but they are read only and they lag behind.

The mistake worth avoiding is choosing the third when the first was intended. A subscription looks like a merge for about a day, and then diverges quietly.

Sharing one account's calendar with the other

This is the direct method, and it is the one to try first.

In Google Calendar, signed into the account that owns the events, open Settings and find that calendar in the list of calendars belonging to that account. Inside there is a section for sharing with specific people or groups. Add the second Gmail address, choose a permission level, and save. The second account receives an email with a link. Opening that link adds the calendar, after which it sits under Other calendars in the left column of the second account and can be toggled on and off like any other.

The result is the first outcome above. Two calendars, one grid, separate colours, no copying, and changes appear immediately in both places because there is only one copy of the data.

Two things commonly block this. Work accounts run by an organisation can have external sharing restricted by an administrator, in which case the second address is either refused or limited to free and busy information regardless of what is selected. And the invitation email sometimes never arrives, which is usually a filtering problem. The calendar can still be added from the second account by using the option to subscribe to a calendar and typing the first account's address directly, since the permission is already granted on the other side.

What the five permission levels decide

The five levels are not cosmetic. They decide whether the combined view is useful or merely decorative.

Permission	Titles and details visible	Can edit events	Can create events on that calendar
See only free/busy (hide details)	No	No	No
See event details	Yes	No	No
Make changes (see private events as free/busy)	Yes, except events marked private	Yes, except events marked private	Yes
Make changes and see event details	Yes	Yes	Yes
Make changes and manage sharing	Yes	Yes	Yes

For two accounts belonging to the same person, make changes and see event details is the level that removes friction, because it allows an event to be created directly on the other calendar without switching accounts. Free/busy only is the right level for someone else's calendar and the wrong level here, since a grid full of unlabelled blocks answers no useful question.

The middle editing level exists for a narrower case. It hides events marked private while still allowing everything else to be edited, which matters when one of the two accounts is a work account and personal entries should stay unreadable from it. For two accounts that both belong to you and hold nothing you need to hide from yourself, it adds a restriction with no benefit.

The secret iCal address, and why it disappoints

Every Google calendar can publish a private address in iCal format, found under the calendar's settings in the section for integrating the calendar. Pasting that address into the other account, using the option to add a calendar from a URL, does produce a combined view. It is also the method most likely to cause a bad week.

Subscribed feeds are read only. Nothing can be edited or created on them from the second account.

More importantly, the refresh interval belongs to Google, not to the subscriber. An event added on one side does not appear on the other side within seconds. It appears when the feed is next fetched, which can be many hours later. For a calendar that changes during the day, that delay turns the combined view into a source of wrong answers rather than a single source of truth.

The address is also a credential in disguise. Anyone holding it can read the calendar without signing in to anything, which makes it a poor thing to paste into a browser on a shared machine.

There is a narrow case where it is the right tool. If the calendar rarely changes, if read only is acceptable, and if the two accounts genuinely cannot be linked by sharing because of an administrator restriction, a subscription is better than nothing. Outside that case, sharing wins on every axis.

Importing is a move, not a merge

Exporting events as an .ics file from one account and importing them into the other is the third method, and it is frequently suggested. It does exactly one thing: it copies the events that exist at that moment into the destination calendar.

After the import, the two calendars are unrelated. New events on the source do not appear. Edits do not propagate. Deleting an event on one side leaves it on the other. Repeating the import to catch up creates duplicates, because the import has no way to recognise events it has already copied.

That makes it correct in one situation and wrong in all others. When an account is being closed, an import moves the history somewhere it will survive. When both accounts stay in use, an import creates two diverging copies of the same schedule, which is worse than having them in separate places, since at least separate places are honestly separate.

Reading both accounts in one app instead

Sharing solves the problem inside Google Calendar. A desktop calendar app solves it one level up, by connecting to both accounts directly.

Both Google accounts are added to the app, and every calendar in both of them renders in one window. Nothing is shared between the accounts and no administrator permission is involved, because the app is signed in to each account separately and simply draws them together. For two work accounts under different organisations, where external sharing is blocked on both sides, this is often the only method that works at all.

It also fixes the part sharing does not fix, which is where new events go. In the browser, the account being viewed determines the default calendar for a new event, and getting that wrong is how a personal appointment ends up visible to colleagues. In a desktop app every event is created with the target calendar chosen at that moment, in one list, which makes the mistake much harder to make. The account connections and calendar selection are covered in the Guide, and how events get created without switching context is described under Entering events.

One detail catches people out. Third party clients connecting to Google over the standard calendar protocol only see the sub calendars marked as visible for external clients in the Google account's own sync settings. A calendar that appears in the browser but not in the app is almost always this setting rather than a failure of the app.

Choosing between the methods in one pass

The decision comes down to three questions, answered in order.

Does either account belong to an organisation that restricts external sharing? If yes, sharing is out for that direction, and the choice is between a subscription and an app holding both accounts. A subscription is read only and delayed, so unless the calendar barely changes, the app is the answer.

Does anything need to be created or edited across the boundary? If a personal appointment ever needs to be added to the work calendar, or the reverse, then read only methods are ruled out. Sharing at the make changes to events level, or an app connected to both accounts, are the two options left. If sharing is available, take it, because it costs a minute and requires nothing new to be installed.

Is switching accounts the actual pain, or is it the switching plus everything else? This is the question people skip. Sharing puts both calendars in one grid inside the browser, and that is genuinely enough for someone who mostly reads the calendar. It changes very little for someone whose day involves creating events constantly, in meetings, on a phone, between other tasks, since the friction there is in capture rather than in visibility.

A useful test is to count, over three days, how many times both calendars needed to be open at once and how many times an event was created in the wrong place. If the first number is high and the second is near zero, sharing solves it. If the second number is not zero, the problem is where events are created, and no amount of sharing will touch that.

Duplicates, defaults, and invitations

Once both calendars are visible, three predictable annoyances show up.

The same meeting appears twice. This happens when both addresses were invited to one event. It is not a sync fault. The event genuinely exists on both calendars, because both accounts were invited. The fix is to decline on one address, or to accept the habit of a single canonical address for external invitations.

New events land in the wrong place. In the browser, the default is tied to whichever account is being viewed. Every event creation screen has a calendar selector, and the ten seconds spent checking it is cheaper than moving the event afterwards, since moving an event that already has guests re-sends the invitation.

Notifications double. Two accounts means two sets of alerts for the same shared meeting. Notification settings are per calendar, so alerts can be switched off on the secondary copy while keeping the events visible.

None of these are solved by a better method of combining. They come from having two accounts, and the only real reduction is deciding which address is the one given to other people, then treating the other as internal.

What to change first

Start with sharing, since it costs nothing and takes about a minute: share the calendar from the account with fewer external constraints, at the make changes to events level, and check the result in the other account. If an administrator blocks it, or if new events keep landing on the wrong calendar, move the whole problem into one app that holds both accounts at once. Caltimate reads several Google accounts in one window and asks which calendar an event belongs to at the moment it is created.