Installing the Chrome browser on a Mac: the steps that matter later

The install itself is four steps and takes about two minutes. Almost nobody searches for it twice. What sends people back to search a week later is everything that follows: the profile that mixed two Google Accounts together, the bookmarks that never arrived, the update that silently did not apply because the application ended up in the wrong folder. Those are all decisions made in the first ten minutes, and they are cheap to make correctly and tedious to undo.

The one check worth making before downloading

Chrome's system requirements for macOS are a single line. Google's own documentation states that to use Chrome on Mac, "you need macOS 13 Ventura and up", and the same requirement appears on the download page. There is no processor caveat and no separate build to pick, unlike Windows, where the requirements split by Intel and ARM, or Linux, where they split by distribution and CPU.

On an older Mac that cannot run Ventura, the download will still complete and the application may still launch, but it is outside what Google supports, which in practice means security updates stop arriving. That is a different situation from an unsupported feature. A browser that no longer receives updates is the single most exposed application on a machine, so an older Mac is a reason to reconsider the browser rather than to proceed carefully.

There is one more thing worth knowing before the search begins, because it costs people real time. Searching the App Store for Chrome returns a listing published by Google LLC, and that listing is the iPhone and iPad application. Its minimum requirement is iOS 18.0. There is no Google-published Chrome for macOS in the Mac App Store, so the Mac version has to come from Google's own site. Anyone who has ever clicked Get on that listing from a Mac and wondered why nothing appeared in the Applications folder has met this already.

The install, following Google's own steps

Google's installation instructions for macOS are four steps, and each one has a reason worth knowing.

Download the installation file. Open the file named "googlechrome.dmg." On the window that opens, Chrome appears. Drag Chrome to the Applications folder. Google notes that an admin password may be required at this point, and adds a fallback: if the admin password cannot be entered, drag Chrome to a location where full permissions exist, such as the desktop.

That fallback is where a lot of quiet trouble starts. It works, and the browser runs perfectly well from the desktop or from a user folder, but the position has consequences described in the next section. On a personal Mac the admin password is available, and taking the extra moment to put the application in Applications is worth more than it appears.

The final step is cleanup, and it is the one most people skip. Google's tip is to eject the mounted image afterwards, using the eject control next to "Chrome" in the Finder sidebar. Skipping it leaves a disk image mounted, and the usual symptom is a second Chrome icon in the Finder that launches a browser which cannot be updated, because it is running from a read only image rather than from the installed copy. Anyone who has two Chrome icons and cannot work out which one is real is almost always looking at an unmounted installer from months ago.

Why the Applications folder matters for updates

Chrome updates itself, and where it lives changes how. Google's documentation says that updates normally happen in the background when the browser is closed and reopened, and that a pending update can be applied manually from the More menu, then Help, then About Google Chrome, then Relaunch. When no Relaunch option appears, the browser is already current.

The Mac-specific note is the interesting one. Google states that automatic browser updates can be set up for all users of the computer if Chrome is installed in the Applications folder, from the About Google Chrome screen, by clicking "Automatically update Chrome for all users". That option depends on the install location. A copy sitting on the desktop or in a user folder cannot offer it.

Two habits follow from this. The first is to visit About Google Chrome once after installing, to confirm a version number appears and to take the all-users update option if the machine is shared. The second is to quit the browser fully now and then rather than leaving it running for weeks, because background updates apply on close and reopen. Google notes that open tabs and windows are restored when Chrome restarts, with the exception of Incognito windows, so quitting deliberately costs almost nothing.

Defaults and imports: two prompts worth answering on purpose

Two setup questions arrive early and both tend to get dismissed.

Setting Chrome as the default browser on macOS is done from within Chrome itself: the More menu, then Settings, then the "Default browser" section, then Make default. Google notes that if the button is missing, Chrome is already the default. The decision is worth making explicitly rather than by reflex, because the default browser is what receives every link clicked in Mail, Slack, Messages and every other application on the machine. On a Mac where work happens in one browser and personal browsing in another, the default is the one that gets the accidental clicks.

The import is the other prompt. Google's documentation lists what can travel from another browser: browsing history, default homepage, bookmarks, default search engines and saved passwords. Bookmarks from Safari or Firefox come across by exporting them to an HTML file from the old browser, then in Chrome choosing the More menu, Bookmarks and lists, Import bookmarks and settings, then Choose file.

One detail in that documentation prevents a specific panic. If Chrome already had bookmarks, imported ones are not merged into the bookmarks bar. They land in a folder named "Other bookmarks" at the end of the bar. Nothing was lost; it is simply not where the eye expects it. Importing on a fresh install avoids the question entirely, which is an argument for doing it in the first ten minutes rather than a month later.

Passwords travel on a different path from bookmarks. Google's documentation points to importing them with Google Password Manager in Chrome rather than through the bookmarks import, so anyone moving off Safari has two separate jobs rather than one. Doing the passwords second is the safer order, because it is the step most likely to need the old browser open alongside the new one.

Set up profiles before signing in, not after

The most common regret after installing Chrome on a Mac is a single profile holding two Google Accounts. It works, and then it produces a steady trickle of small failures: a shared document that says access is needed, a calendar invitation sent from the wrong address, a link from a work channel that opens under a personal identity.

Chrome's own documentation is clear about what profiles are for, describing them as ideal for sharing a computer and for keeping different accounts, such as work and personal, separate. A profile is added from the profile button at the top right, then Add Chrome profile, then choosing a name, photo and colour scheme. Profiles can be shown at startup by checking "Show on startup" under Manage Chrome profiles, which turns the choice of identity into a deliberate step rather than an accident.

One concrete example shows why the separation is structural rather than cosmetic. Google's documentation on working offline in Docs and Sheets states that only one account for each browser profile can have offline access enabled, and that enabling it for several accounts requires creating them on separate browser profiles. That is not a preference. It is a limit that no amount of switching accounts inside Google's own interface can work around.

The cost is worth stating plainly too. Google warns that after a profile is removed, that profile's bookmarks, history, passwords and other settings are erased from the computer. Profiles are cheap to create and not free to delete, which is a reason to name them for roles rather than for moods.

Safari, already on the machine, takes the same approach under a different name, which is worth knowing for anyone deciding how much to move. A Safari profile is created from Safari settings, then Profiles, then the add control, giving the profile a name, an icon, a colour and its own bookmarks folder, with extensions selected per profile. Switching is done through File, then New Window, then that profile's own window command. Apple notes two things that matter for a work and personal split: passwords stored in iCloud Keychain remain available in any profile created, and deleting a profile erases the tabs, history and website data belonging to it while preserving its favourites folder. The practical reading is that both browsers separate browsing state cleanly and neither separates stored credentials, so a profile is a boundary around sessions rather than around identity as a whole.

What a second browser still does not solve

Profiles fix isolation. They do not fix routing, and the difference is where most carefully built setups quietly fail.

Setup	Separate signed-in state	Separate notification permission	Offline Docs per account	Links land in the right place
One Chrome profile	No	No	One account only	Not applicable
Several Chrome profiles	Yes	Yes	Yes, one per profile	No, whichever window is frontmost
Chrome plus a second browser	Yes	Yes	Yes	Only by choosing the browser first
A browser that keeps each web app in its own window	Yes	Yes, per window	Depends on the engine	Yes, bound per app

Read down the last column. Two Chrome profiles genuinely hold two independent identities, and then macOS hands a clicked link to whichever browser window happens to be in front. A work link arriving in the personal profile produces an access error that looks like a permissions problem and is actually a routing problem. Choosing the right window before clicking is the only remedy the browser itself offers, and it is a remedy that depends on remembering.

The other half of the problem is density. One window holding fifteen web applications means fifteen services competing for the same keyboard shortcuts and the same window. A browser that keeps each web app in its own window changes that arithmetic, which is what an app aggregation browser is built for, and binding a specific service to a specific workspace is what addresses routing rather than isolation. For a single Google Account and light browsing, Chrome with one profile is the correct answer and nothing more is needed. The calculation changes at the point where two identities and a dozen services are in play daily.

What to change first

Confirm the copy is in the Applications folder, open About Google Chrome once to check the version and take the all-users update option, then import bookmarks and create a second profile before signing in to a second Google Account. If links keep opening under the wrong identity after that, the missing piece is routing rather than isolation, which is what SpaceDeck is built around.