Merging calendars from two Google accounts

Two accounts, one day. The work calendar has the meetings, the personal one has the dentist and the flight, and neither knows the other exists. The result is the same every time: something gets booked over something else, and the fix arrives after the apology.

Searching for a way to merge them turns up a dozen tutorials that all start with different steps, because the word merge covers at least three separate operations in Google Calendar. Picking the wrong one is how people end up with duplicated events, a calendar that stopped updating months ago, or a work meeting whose title is visible to a personal account that should never have seen it.

Google does not have a merge button, and that is the useful starting point

There is no single control that fuses two accounts. What exists are three mechanisms, and each solves a different problem.

The first is seeing both accounts in one grid while both stay separate. Nothing moves. The events keep their original owner, and edits made in one place show up everywhere within seconds. This is what most people actually want, and it is the cheapest option.

The second is copying events from one account into another, usually because one account is being closed or abandoned. This is a one time transfer. After it runs, the two copies have no relationship at all.

The third is letting one account see whether the other is free, without exposing what the commitment is. This matters for anyone who books time with clients while keeping a private life private.

Deciding which of the three applies takes about ten seconds and saves a lot of undoing. If both accounts will still be in use next month, the answer is almost always the first one, and everything below about export and import can be skipped.

Sharing one account's calendar with the other

Sharing is the mechanism built for two accounts that both stay alive. It works between two personal Gmail accounts, between two work accounts, and in most cases across the two.

On the account that holds the calendar, open Google Calendar settings, find the calendar under the list of calendars you own, and open the sharing section for it. Add the other account's address, choose a permission level, and save. The other account receives an email with a link. Clicking that link is what actually adds the calendar to the second account's sidebar, and skipping it is the single most common reason someone reports that sharing did not work.

The permission chosen at that moment decides everything afterward.

Permission level	What the other account sees	What it can do
See only free/busy	Blocks marked busy, no titles or guests	Nothing
See all event details	Titles, times, location, guest list	Nothing
Make changes to events	Full detail	Create, edit, delete
Make changes and manage sharing	Full detail	Everything above, plus grant access to others

Two details are easy to miss. Sharing is per calendar, not per account, so an account holding five calendars needs five separate sharing steps. And the calendar stays owned by the original account. Deleting that account, or losing access to it, takes the shared calendar with it.

Notifications are the third thing people expect to arrive and do not. Alerts belong to the account that owns the event, so a shared calendar shows up silently at first. Notification settings for a calendar received from someone else are set separately in the receiving account, and they have to be turned on deliberately. Anyone who shared a partner's calendar and then missed the appointment on it has met this behaviour already. Set the notifications at the same time as the sharing, or the merged view will be accurate and still useless at the moment it matters.

Export and import copies events, it does not connect them

The export function produces a zip file containing one .ics file per calendar in the account. Unzip it, then import the individual .ics files into the target account, choosing which calendar receives each one. Import runs one file at a time.

What arrives is a copy taken at that moment. Recurring events keep their repetition rule. What does not survive is the relationship to the original meeting: the copy has a new organizer, so replies from guests and later changes made by the person who created the meeting will not reach it. A copied event of a meeting that gets moved next week will sit in the wrong slot forever.

The format underneath all of this is an open one, which is why the same file works between different calendar products.

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. Source: rfc-editor.org

Import is the right tool when an account is going away and its history needs to be preserved somewhere. It is the wrong tool when both accounts will keep running, because from the moment it finishes, every event exists twice with nothing linking the two copies.

Where duplicates come from, and how to stop reading them twice

Duplicates in a merged view almost always come from one of three places.

• Both accounts were invited to the same meeting, so both hold a legitimate copy
• An import was run on top of a calendar that was already shared
• The same calendar was both shared directly and subscribed to by its secret address in iCal format

The first is not a bug and cannot be removed at the source. Decide which account is the one that receives invitations, and use that address consistently when booking with other people. The second is repaired by deleting the imported copies, which is tedious enough to be worth avoiding in the first place. The third is the easiest to fix and the most damaging while it lasts, because a subscription by secret address refreshes on Google's own schedule rather than instantly. Two Google accounts that can share directly should share directly. Subscription by URL is for calendars that are not Google accounts at all.

After the source is settled, colour is what makes a combined grid readable. One colour per account, not per calendar, so a glance answers the only question that matters at speed: which life does this block belong to. Colour set on the receiving side is local, which is convenient. Recolouring a calendar someone shared does not change how it looks to them.

The other half of readability is deciding what to hide. A merged view that shows every calendar from both accounts, including birthdays, holidays, and a subscribed sports fixture list, is not a merged view. It is noise with a few real commitments buried in it. Most accounts carry two or three calendars that genuinely hold decisions and several that hold reference material. Leave the reference ones switched off during the working day and turn them on when they are needed. The point of combining accounts is to see conflicts, and a conflict is only visible when the grid is sparse enough to read.

Doing it at the app layer instead of inside the accounts

Sharing solves the problem inside Google's web interface. The other route solves it on the machine, by adding both accounts to one calendar client and letting the client draw them together.

On macOS, both accounts can be added under Internet Accounts in System Settings, with Calendars enabled for each. Apple Calendar then shows every calendar from both accounts in one window. A third party calendar app for Mac does the same thing and usually adds what the built in app leaves out: colour by account, quick toggles to hide a whole account, and a single agenda list that ignores which account an event came from. The list of what a desktop calendar can pull together across accounts is worth reading before installing anything, and the Features page covers the shape of it.

There is a second reason to prefer the app layer, and it has nothing to do with features. Sharing changes what an account can see, permanently, until someone remembers to undo it. A client on a laptop changes nothing on Google's side at all. If the arrangement is temporary, if the second account belongs to a contract that ends in March, or if the personal account should not be structurally linked to the work one, the app layer is the reversible option. Removing the account from the machine ends the arrangement completely.

One known trap: a calendar that was shared to an account does not always sync to desktop and mobile clients by default. It appears on the web and stays missing in the Mac app. Google keeps a separate setting for which calendars sync to clients, and that setting is where a missing calendar usually turns out to be switched off. If a calendar is visible in a browser but absent in the app, check there before reinstalling anything.

Work and school accounts follow the administrator's rules

A Google Workspace account belongs to an organisation, and the organisation decides how much of it can leave. An administrator can allow full detail sharing outside the domain, restrict external sharing to free/busy only, or block external sharing entirely.

When sharing a work calendar to a personal address produces nothing, and the steps were followed correctly, the restriction is the explanation. No amount of retrying changes it, and the workaround people reach for next, forwarding invitations to the personal address, creates copies that drift out of date.

The app layer is unaffected by that particular restriction, because signing a Mac client into the work account is not sharing. It is the account holding its own data on its own device, subject to whatever device policy the organisation applies. For a lot of people this is the practical answer: one window, both accounts, nothing shared with anybody.

Seeing availability without exposing the details

There is a version of this problem where full merging is the wrong goal. A freelancer with a client facing account and a personal one needs the personal commitments to block time, not to be readable.

Free/busy permission is built for exactly that. The second account sees a block marked busy with no title, no guests, and no location, which is enough to prevent a double booking and not enough to reveal anything. Combined with a client showing both accounts at once, it produces a day that is complete and still private.

If the account offers appointment scheduling for publishing open slots to other people, check which calendars that feature consults for conflicts before publishing anything. A booking page that only checks one calendar will happily sell a slot that is already taken on the other. Getting the gaps right is a separate job from getting the events right, and the Travel time section covers the part that most schedules lose.

What to change first

Decide whether both accounts are staying. If they are, share the calendars in both directions and never import anything, then add both accounts to one Mac client so the day is visible in a single window. If one account is being retired, export it, import it once, and stop using it the same day. A Mac calendar built for multiple Google accounts removes the second half of that work, but the sharing decision has to be made first either way.