Adding a second account to Google Calendar
The second Google account usually arrives without being asked for. A workplace hands one out, a client insists on theirs, a side project gets its own. The calendar that matters most is rarely the one already open, and the day only makes sense when both are visible at the same time.
Searching for how to add another account to Google Calendar generally leads to one instruction: click the profile picture, choose add another account, sign in. That instruction is correct, and it does not solve the problem most people have. It adds the account to a switcher. It does not put both sets of events into one grid. Those are different results, and knowing which one is needed saves a lot of pointless clicking.
What adding an account actually changes
Google Calendar on the web is built around a single active account. Everything on screen belongs to whichever account is currently selected: the calendars in the left column, the colours, the default calendar for new events, the notification settings, the working hours. Adding a second account creates a second, parallel version of all of that. It does not merge anything.
The practical effect is that the browser now holds two complete calendars that never touch. Switching between them takes a click or two, which sounds trivial until it happens forty times a day. The real cost is not the clicks. It is that a schedule which requires an action to become visible stops being consulted. People check the calendar in front of them and forget the other one exists, which is how a meeting gets booked into a slot that was already taken.
This matters because the two problems get confused constantly. One problem is access: being able to reach the second account at all. The other problem is visibility: seeing both days at once, in one grid, colour coded, without a switch. The account switcher solves access. It was never designed to solve visibility, and no amount of configuring it will make it do so.
So the first decision is which of those two problems is the actual one. If the second account is opened once a week to check something, the switcher is enough and the rest of this is unnecessary. If events are being created and moved across both accounts every day, the switcher is the wrong tool and the section on getting both into one view is where the answer is.
Adding the account in the browser
The steps have not changed in years. Open Google Calendar in a browser, click the profile picture in the top right, and choose to add another account. A sign in screen appears. After signing in, the browser is authenticated for both accounts at once, which Google calls multi login.
From that point, the profile picture menu lists every signed in account, and choosing one opens that account's calendar. The address bar shows which account is active through an index number: the first account signed in is at /u/0/, the second at /u/1/, and so on. That index is worth knowing, because it is stable enough to bookmark. A bookmark pointing straight at /u/1/ skips the menu entirely.
The index is assigned in the order the accounts were signed in during that browser session, not by any account setting. Signing out of everything and back in can renumber them, which is the reason a bookmark that worked last month sometimes opens the wrong calendar. When that happens, the fix is to re-check the index rather than to assume the bookmark broke.
When multi login is blocked
Some organisations disable multi login for managed accounts. The symptom is that adding the personal account signs the work account out, or the second account refuses to load and returns to the sign in screen. This is set by an administrator and cannot be changed from inside the account.
Separate browser profiles
The alternative that survives most restrictions is a separate browser profile for each account. Chrome, Safari and Firefox all support profiles or separate windows with independent sign in states, so each profile holds exactly one Google account and nothing collides. Two windows sit side by side, each pinned to one calendar.
This is more reliable than multi login and slightly heavier. It also has an accidental benefit: extensions, bookmarks and saved passwords stay separated along the same line as the calendars, which is usually the line that matters.
The mobile app behaves differently
This surprises people who assume the web version is the complete one. The Google Calendar app on a phone can hold several accounts at once and draw all of their calendars into the same grid. Each account's calendars appear in the side menu with its own checkboxes, and events from both are laid out together, colour coded, in a single day or week view.
The reason for the difference is that the mobile app reads accounts registered on the device rather than sessions in a browser. Once two Google accounts exist on the phone, the calendar app treats them as sources to draw from, not as separate logins to switch between.
That has a useful consequence. Anyone who feels the calendar works better on the phone than on the Mac is usually not imagining it, and the cause is not screen size. The phone is genuinely doing something the browser does not do. It merges. Naming the difference correctly is what points at the fix, because the same merging behaviour is available on a Mac through a desktop calendar application, and not through the browser.
Three ways to see both accounts at once
There are exactly three approaches that produce a single combined view, and they differ in what they cost and what they give up.
The first is sharing. From the account that holds the events, open that calendar's settings, find the section for sharing with specific people or groups, and add the other account's address with a permission level. The other account receives a link, and after accepting it the calendar appears in its own left column alongside its native calendars. Nothing is duplicated, so changes appear instantly.
The second is subscribing to the secret address in iCal format, found in each calendar's integration settings, and adding that address in the other account under the option to add a calendar from a URL. This works when sharing is blocked, and it produces a read only copy that Google refreshes on its own schedule rather than immediately. Events shown this way can be out of date.
The third is a desktop calendar that signs in to both accounts separately and draws everything in one window, in the same way the phone app does. Nothing is shared between the accounts and nothing is copied, so administrator restrictions on sharing do not apply.
| Method | Both accounts in one grid | Events stay current | Can create events in either account | Blocked by an administrator |
|---|---|---|---|---|
| Account switcher | No | Yes | Yes, one at a time | Sometimes |
| Sharing | Yes | Yes | Only with change permission | Often |
| Secret iCal address | Yes | No, refreshed on Google's schedule | No, read only | Rarely |
| Desktop calendar app | Yes | Yes | Yes | No |
Why exporting and importing is not a fourth option
Google Calendar can export a calendar as an ICS file and import that file into another account, and it looks at first glance like the cleanest answer. It is not a way to see two accounts at once. It is a one time copy. The events land in the second account and then stop tracking the original, so every later change has to be copied again by hand, and running the import a second time produces duplicates rather than updates.
That makes exporting genuinely useful in exactly one case: an account being retired. When one address is going away for good and its history needs to survive, exporting and importing moves the events across once and the divergence never matters, because nothing is left behind to diverge from. For two accounts that are both still in daily use, it creates a maintenance job that grows every week.
What the permission level decides
The permission level in the sharing method decides more than it appears to. Free or busy only produces a wall of unlabelled blocks. Seeing all event details makes the calendar readable but still read only. Only the permission to make changes to events allows creating an event on the other account's calendar without switching, which for two accounts belonging to the same person is normally the right setting. A guide to entering events covers what changes once creation stops depending on which account is active.
Choosing which calendars a desktop app can see
There is a setting that quietly breaks the third approach, and it is easy to miss because it lives outside the normal settings screen. Google keeps a separate list of which sub calendars are exposed to external clients, at the sync selection page under calendar.google.com. Anything switched off there is invisible to a Mac calendar application even though it displays perfectly in the browser.
The usual symptom is a single missing calendar. Both accounts connect, most events arrive, and one specific calendar never appears. Before reinstalling anything or deleting and re-adding the account, that list is the first place to look. Turning the calendar on there and refreshing the account in the application is normally the whole fix.
A second cause of the same symptom is a shared calendar that was accepted in the browser but never enabled for external access. Google's own help pages on managing calendars describe both switches, and they are separate on purpose, so having one enabled says nothing about the other.
What starts going wrong once both are visible
Combining two accounts solves the visibility problem and immediately creates three smaller ones. They are predictable, and they are worth handling deliberately rather than gradually.
The same meeting appears twice. When both addresses are invited to one event, that event genuinely exists on both calendars. It is not a sync fault and it will not resolve itself. Declining on one address removes the duplicate, and settling on a single address for external invitations prevents the next one.
New events land on the wrong calendar. Every creation screen has a calendar selector, and the default follows whichever account is active. Choosing the calendar before saving costs a couple of seconds. Moving an event afterwards re-sends the invitation to every guest, which costs considerably more.
Notifications fire twice. Two accounts means two sets of alerts for the same shared meeting. Notification settings are per calendar, so alerts can be turned off on the secondary copy while the events stay visible.
Only the second and third of these are tool problems. The first is a decision about which address other people are given, and it survives every possible method of combining calendars. Separating the two kinds of problem prevents a lot of wasted configuration.
What to change first
Start by naming which problem is real. If the second account is consulted occasionally, add it through the profile menu, bookmark its /u/1/ address, and stop there. If events are created across both accounts every day, the browser is the wrong place to work and one window holding both accounts is the change worth making. Caltimate signs in to several Google accounts at once, draws them in a single view, and asks which calendar an event belongs to at the moment it is created.
Frequently asked questions
Does adding another account merge the two calendars?
No. Adding an account through the profile picture menu creates a second, separate calendar view that is reached by switching. The events are never drawn in the same grid. To see both at once, the calendar has to be shared between the accounts, subscribed to by URL, or opened in an application that signs in to both.
How many Google accounts can be signed in at the same time?
Google's multi login supports several accounts in one browser at once, and the practical limit is rarely reached with two or three. The more common blocker is an administrator disabling multi login for a managed work account, which shows up as the second account failing to load rather than as a numeric limit.
Why does one calendar show in the browser but not in a Mac calendar app?
Google keeps a separate list controlling which calendars are exposed to external clients, and it is not the same as the visibility checkboxes in the browser. A calendar switched off in that list is invisible to desktop applications while looking completely normal on the web. Enabling it there and refreshing the account fixes it.
Is it safe to use the secret iCal address to see a work calendar?
The address grants read access to everything on that calendar to anyone who holds it, so it should be treated like a password and never posted anywhere shared. It can be reset from the same settings screen if it leaks. It is also read only and refreshed on Google's schedule, so it is a poor choice for a calendar that changes during the day.