What Chrome guest mode is actually for

Chrome shows three kinds of window that look almost identical and behave very differently. A normal profile window, an incognito window, and a guest window. The word "profile" appears on all three surfaces, which is why the guest option gets treated as just another profile to switch into. It is not. A profile exists to keep things. Guest exists to keep nothing. Choosing the wrong one for daily work means logging in again every single morning, and that cost is invisible until it has been paid for a few weeks.

What a profile is, in concrete terms

A Chrome profile is a directory on disk. On macOS the profiles sit under ~/Library/Application Support/Google/Chrome/. The first one is Default, and each profile added afterwards becomes Profile 1, Profile 2, and so on.

Inside each directory are separate stores for bookmarks, history, cookies, saved passwords, autofill data, extensions, and site permissions. Nothing crosses between them. Signing in to Gmail in one profile does not sign you in anywhere else, and a bookmark saved in one profile is invisible from another.

The display name shown in the interface is decorative. A profile renamed to "Work" still lives in a folder called Profile 1. The mapping between folder names, display names, and signed-in addresses is stored in a file named Local State in the parent directory. The current window's folder is visible at chrome://version, on the Profile Path line.

A profile is the unit of identity in Chrome. Everything that persists belongs to exactly one of them.

What guest mode is instead

Guest is not an entry in that list of directories. It is a temporary session that exists only while guest windows are open. Nothing about it survives the last guest window being closed.

Practically, that means a guest window loads no bookmarks, offers no saved passwords, runs no extensions, and cannot sign in to Chrome sync. Websites can still be signed into normally, but those sessions disappear along with everything else when the window closes. History, cookies, cache, and form data all go with it.

One detail catches people out. Every open guest window shares a single guest session. Two guest windows cannot hold two different accounts for the same service. If the goal is two logged-in identities side by side, guest is structurally the wrong tool, no matter how many windows are opened.

Guest against incognito against a second profile

The differences are easiest to see next to each other.

Behaviour	Guest window	Incognito window	Normal profile
History saved	No	No	Yes
Bookmarks visible	No	Yes, from the parent profile	Yes
Saved passwords offered	No	Yes	Yes
Extensions loaded	No	Disabled by default, can be allowed	Yes
Chrome sign-in and sync	Not available	Inherited from the parent profile	Available
State after closing	Discarded	Discarded	Kept

The practical dividing line is whether the parent profile's bookmarks and passwords should be reachable. For checking how a page looks while logged out, incognito is fewer steps, because the bookmark bar is still there to open the page from. For handing the machine to another person, guest is the honest choice, because nothing personal is on screen to begin with.

Neither one hides traffic from a network administrator, an employer, or the sites being visited. They control what is written to this machine, not what is observable elsewhere.

When guest is the right answer

Guest earns its place in a small, clear set of situations.

• Lending a Mac to someone for a few minutes without exposing bookmarks, history, or saved passwords.
• Checking how a page behaves for a signed-out visitor, which matters for anything with member-only content or sharing permissions.
• Working briefly on a shared or borrowed machine, where leaving no local trace is the point.
• Isolating an extension problem. Because guest loads no extensions, a rendering fault that disappears there is very likely caused by an extension in the normal profile.

Outside those cases, guest tends to create work rather than remove it. It cannot carry a task from one day to the next, and it cannot hold two accounts at once.

When the guest option is missing

If the avatar menu shows no guest entry, the usual cause is policy. Chrome exposes an administrative setting that turns guest browsing off, and managed devices issued by an employer or a school often have it disabled for audit reasons. That setting cannot be reversed from the user side of the interface.

The other common cause is a Chrome installation with no profile configured yet, where the avatar menu is reduced to a shorter set of options. Creating one profile usually brings the full menu back. It is also worth separating Chrome profiles from macOS user accounts, since they are different layers. Switching macOS users changes which Chrome data directory is in play entirely, which can make a familiar setup look wrong.

What a profile does not separate

Profiles are often assumed to be a clean partition of everything. They are not, and the gaps matter when the split exists for a work reason rather than a convenience one.

Downloads land in one place. Every profile writes to the same download folder by default, so a file pulled from a work account sits next to personal files with nothing marking which session produced it. Changing the download location is a per-profile setting, which is worth doing deliberately if the separation is meant to be real.

The browser itself is shared. There is one Chrome application, one version, one update cycle, and one set of processes. A crash that takes down the browser takes down every profile window with it. A flag or a policy applied at the browser level applies everywhere.

The operating system sees one browser too. Whichever profile last granted a notification permission produces notifications that look identical to any other, and the default browser handler that opens a link from Mail or Slack points at Chrome rather than at a specific profile. That last point is the source of a very common irritation. A work link clicked in a chat app opens in whichever profile window Chrome decides to use, not the one the link belongs to.

Password storage also has a shared component on macOS. The encryption key protecting saved passwords is held in the login keychain, so the isolation between profiles is enforced by Chrome rather than by the operating system. That is sufficient for organising work. It is not the same as two separate user accounts on the Mac, and it should not be treated as a security boundary against someone with access to the logged-in machine.

Deleting a profile is immediate

Removing a profile from the profile manager deletes its data. There is no confirmation stage that keeps a copy, no trash to recover from, and no undo. Bookmarks, history, saved passwords, and extension data belonging to that profile go at once.

Anything worth keeping should be exported before the deletion. The bookmark manager writes an HTML file that any browser or profile can import, and saved passwords can be exported from the password settings as a CSV file, which should be deleted again once it has been imported somewhere safe.

If sync was enabled and the account is not being removed, the data still exists on the Google account, and signing in again from a new profile pulls it back. If sync was never enabled, the local copy was the only copy.

There is also a slower failure worth naming. Profiles accumulate. Each one added for a single client project or a one-off login stays in the switcher afterwards, and a switcher with nine entries is harder to use than the tab strip it was meant to fix. Reviewing the list occasionally, exporting what matters, and removing what has not been opened in months keeps the mechanism usable.

Where adding profiles stops helping

Adding a second profile solves the account problem cleanly. It does not solve the two problems that follow it.

The first is identification. Switching profiles opens a new window, and that window looks like every other Chrome window. Same icon in the Dock, same shape, same position on screen. The only marker is a small avatar in the corner. Anyone switching a dozen times a day will eventually type into the wrong one, and the most common report of it is bookmarks appearing to have vanished when in fact a different profile is on screen.

The second is that profiles divide by account, not by work. Inside one profile, mail, chat, documents, and an admin console still share a single tab strip. Splitting accounts does nothing about twenty tabs competing for the same row of pixels. The division that actually reduces the cognitive load is per application, with each one holding its own window and its own session, which is the model described in Workspaces and across the feature set. Which services can be run that way is listed under supported apps.

Making profiles distinguishable before doing anything else

If profiles are staying, three small settings reduce the number of mistakes considerably, and all three take a minute.

Give each profile a distinct theme colour from the customisation panel. Colour is readable from the corner of the eye across a whole screen, which an avatar initial is not. Pairing the colour with a short display name, one word rather than a full email address, makes the switcher legible at a glance.

Turn on the profile picker at startup, in the profile settings. Chrome then asks which profile to open rather than reopening the last one, which stops a morning from beginning in the wrong identity. It costs one click and prevents the class of error where an entire session happens in the wrong place before anyone notices.

Launch a specific profile directly when the choice is known in advance. Chrome accepts a flag naming the profile folder, and the command can be saved, aliased, or bound to a launcher.

open -na "/Applications/Google Chrome.app" --args --profile-directory="Profile 1"

The flag takes the folder name, not the display name, so it needs the value found in chrome://version or Local State. Two details break this in practice. Without -n, an already running Chrome simply brings an existing window forward and ignores the rest of the command. And writing the application name without its full path can match a different Chromium-based application whose process carries the same name.

None of this changes what a profile is. It changes how often the wrong one ends up in front of the keyboard, which is where the real cost sits.

What to change first

Use guest for what it is good at, which is lending the machine, testing a logged-out view, and isolating an extension fault. Use a second profile when two accounts genuinely need to persist. If profiles are being switched several times a day and the wrong window keeps getting typed into, the problem is no longer accounts but windows, and that is the case SpaceDeck is built for.