Bookmarks for Google services: how to do it when you have several accounts
What this is about#
A private account, a company account: running several Google accounts in the same browser is the normal case for me.
Only the bookmarks cause trouble. Bookmark the calendar of your company account, and a few weeks later you land in your private calendar. Or the other way round. Miss it, and you agree to the wrong slots. All that although nobody touched the bookmark.
The way Google writes the account context into the address is to blame:
https://calendar.google.com/calendar/u/1/rThat number is not an account ID, it is an index and therefore a snapshot. Which is exactly why the bookmark does not work. The solution follows right away, the explanation can be found further down.
Generating permanent links#
With this small form you can generate links that keep working, locally and in a few clicks.
Why the number is useless#
The number behind /u/ is the position in the browser’s sign-in order. The account signed in
first gets /u/0/ and is also the default account, the second one /u/1/, the third /u/2/. That
count belongs to the browser’s cookie state, not to the account.
Other services carry the same value in the query parameter authuser:
https://docs.google.com/spreadsheets/d/xxxxx/edit?authuser=1
https://console.cloud.google.com/home/dashboard?authuser=2Switching accounts through the menu in the top right does not change the assignment. It can still flip, and more often than you would think:
- After signing out and back in in a different order,
/u/1/turns into/u/0/. - Cookies deleted, browsing data cleared, “delete everything on exit” enabled.
- Remove one account and every account behind it moves up a position.
- Every other device, every other browser and every private window counts for itself.
- A colleague opens the shared link: for her,
/u/1/points at an entirely different account.
The silent failure is what makes this unpleasant. The link keeps working, it just opens the wrong calendar. You usually notice once an appointment sits in the wrong place.
The problem is not exotic, by the way. A Google-owned open source project documents it as a bug, with the remarkable observation that the correct index cannot be determined through any API.
How the generated link is built#
Instead of a position, you tell Google directly which account you mean. The route goes through Google’s account chooser:
https://accounts.google.com/AccountChooser?source=ogb&continue=https%3A%2F%2Fcalendar.google.com%2Fcalendar%2Fr&Email=marco%40example.comTaken apart, that is only three building blocks:
| Parameter | Meaning |
|---|---|
source | Origin marker, ogb stands for the “One Google Bar” (pure cosmetics). |
continue | The target URL, fully URL-encoded. This is where you go after choosing the account. |
Email | The e-mail address of the account to be used. |
Google looks up the account for that address in the current session, works out the matching index itself and forwards you. If the account is not signed in, you end up on the sign-in page, with the address already filled in.
Alternative solutions?#
The parameter authuser works in principle too. On many services it accepts the address itself
alongside a number:
https://calendar.google.com/calendar/r?authuser=marco@example.comShorter and more readable, yet still the worse choice. authuser only picks between the accounts
currently signed in in this browser. If you are signed in somewhere, just not in the account from
the link, Google does not ask: it silently opens a different account, without a sign-in page and
without a warning. Which puts you back at the problem the link was supposed to solve.
There are also older reports that something like
https://calendar.google.com/calendar/u/marco@example.com/rused to work. As of September 2026 I cannot confirm that. It did not work for me.
Sources#
- What the /u/0 and /u/1 in Gmail URLs and other Google Apps Really Mean ↗ – explains the session index and the sign-in order
- Changing of multiple google account indexing in the URL ↗ – Google Account Community on the shifting assignment
- Change the order of sign in list ↗ – Google Account Community on the sign-in order
- Google tip: Set ?authuser=[email] ↗ – on the e-mail variant of
authuser - Deep links don’t support secondary Google accounts ↗ – a Google-owned project on the same problem, including the finding that the index cannot be determined through any API
