Chrome startup pages: deciding what opens when the day begins

Most people arrive at Chrome startup pages from one of two directions. Either the same four or five web apps get typed in by hand every morning, or the opposite: a previous session restores thirty tabs and the machine crawls for a minute. Both are decided in the same place, in a single settings group with three radio buttons. What the settings screen does not say is that one of those three choices silently switches off other behavior you may be relying on, and that a startup list has a hard limit on what it can fix. This covers the setting itself, the trade-off inside each option, why it sometimes appears locked, and where the approach runs out.

What the "On startup" setting actually controls

In Chrome on a Mac, the group is labeled On startup and sits in Settings. It governs one thing only: what appears when Chrome launches from a fully closed state. It does not govern the Home button, and it does not govern what a new tab shows during the day.

That distinction trips up a lot of people, because a browser has two settings that look like the same idea. The homepage is what loads when the Home button in the toolbar is pressed. Google's own administrator documentation for the homepage setting states it plainly: the homepage is opened using the home button, and on a computer the pages opened at startup are controlled by a separate policy. So editing the homepage will never change the morning screen, and building a startup list will never give you a single page to return to mid-task.

There is a third setting in the same area that adds to the confusion. Whether the Home button is visible in the toolbar at all is its own switch, and it can be set centrally by an administrator. If a homepage was configured and nothing seems different, check whether the button is actually on screen before changing anything else.

Deciding which of the two problems is being solved narrows the work to one control. Shortening the morning means the startup group. Wanting a reset page during the day means the homepage.

The three options, and the trade-off inside each

The radio buttons read Open the New Tab page, Continue where you left off, and Open a specific page or set of pages. Picking the third one reveals a list, plus two ways to fill it: Add a new page, which asks for a Site URL, and Use current pages, which captures whatever is open right now.

Option	What launches	Best suited to	The cost
Open the New Tab page	One empty tab	Machines used for varied, unplanned work	Every app still gets opened by hand
Continue where you left off	Every tab from the last session	Long single projects carried across days	Tab count is whatever yesterday left behind, and other settings get disabled
Open a specific page or set of pages	Only the listed URLs, in list order	A repeating morning routine	The list has to be maintained as the routine changes

Two details about the third option are worth knowing before committing to it. Chrome creates the tabs in list order, so the first entry becomes the active tab at launch. Putting the app that gets the most attention at the top means the first click after startup lands where it should.

The other detail is what happens when the list is empty. Google's administrator documentation states that when no startup URLs are set, the New Tab page opens at startup. So leaving the third option selected with nothing in the list produces exactly the same screen as the first option. A share of the "changed the setting and nothing happened" reports come down to this.

Why "Continue where you left off" turns other settings off

This is the part that step-by-step guides tend to skip. Restoring the last session is not a neutral choice; it makes a category of cleanup settings impossible.

Google's policy documentation for the startup behavior says that when the value restores the last session, settings that depend on the session or that act on exit are partly disabled, and it names two of them: clearing browsing data on exit, and session-only cookies. The logic is straightforward. Carrying the closing state forward and discarding the closing state are opposite instructions, so one of them has to lose.

The practical consequence is a decision, not a workaround. On a shared Mac where cookies are meant to be dropped when the browser closes, restoring the previous session cannot also be true. If the cleanup requirement came first, the third option is the setting that fits it: a fixed list of four to six pages opened fresh each morning, with the exit behavior left intact.

The same documentation describes a fourth behavior that the settings screen does not offer: restoring the last session and opening the configured URLs. In that mode the browser restores the previous session and opens a separate window showing the listed URLs, and it notes that if that window is left open, it will itself be restored in later sessions. Asking for both restoration and a fixed list produces windows that accumulate. That is a useful thing to know even if the option is only reachable through management tooling.

Choosing what goes on the list

The list gets unwieldy fast, and the cure is to count roles rather than URLs. A morning startup generally needs three kinds of page, and one of each is usually enough.

The first is where things arrive: mail, chat, anything whose contents are set by other people. The second is where the day gets ordered: a calendar, a board, a queue. The third is where the work happens: a document, a repository, a design file. Three entries, three roles.

Adding a second page in the same role reintroduces the decision the list was supposed to remove, and it does so every single morning rather than once. Two inboxes at launch means choosing which inbox to read first, every morning, which is the cost the list was meant to eliminate. Reference material, dashboards that get checked once a day, and anything read rather than worked on belong in bookmarks instead, where they cost nothing at launch.

One more practical note on the URLs themselves. For a service used with more than one account, entering the plain top-level address opens whichever account was used last. If a specific account should open, capture the page with Use current pages rather than typing the address, because the captured URL already carries the account selector. Typing addresses by hand is where account-specific startup lists usually break.

When the setting is greyed out

Sometimes the radio buttons are visible but inert, or a change refuses to stick. That is not a fault. It means the value has been fixed centrally.

Google's policy documentation states that when the startup behavior is set by policy, the user cannot change the setting in Chrome, and that leaving the policy unset is what allows the user to change it. Grey therefore means decided elsewhere. The documented values are four: open the New Tab page, restore the last session, open a list of URLs, and open URLs plus restore the last session. The full list of settings an administrator can fix is published in the Chrome Enterprise policy list.

A Mac issued by an employer or a school is the common case. On a personally owned Mac that no organisation manages, a locked setting points somewhere else: a configuration profile installed earlier, or an extension that has taken over the startup behavior and is holding it. Extensions are worth checking first, because the settings screen gives no visible sign that one is involved.

There is a related note in the policy documentation that explains something else. Turning the startup behavior off is treated as the same thing as leaving it unset, because the browser has to have some specified behavior at launch. There is no state in which nothing is decided. Whatever the settings screen shows, one of the documented values is in effect.

Sync is worth a look too. Startup URLs travel as part of settings, and the documented list of data types an administrator can exclude from synchronisation names preferences, which is the category those settings belong to. The same list covers bookmarks, passwords, tabs, themes, extensions and reading list, among others. So if a startup list contains entries nobody remembers adding, the answer is usually on another machine signed in to the same account rather than on this one. Signing out of that other machine does not undo it; the list has already arrived.

What a startup list cannot fix

Everything above removes typing and removes an empty screen at launch. Two problems survive it.

The first is telling the tabs apart. Six startup pages produce six small favicons in a row. When the same service is used with two accounts, the work inbox and the personal inbox look nearly identical, so the first click of the morning lands on the wrong one often enough to be annoying. The second is sign-in state. Putting a URL in the startup list says nothing about whether that session is still authenticated. If one of the two accounts needs signing in again, the list delivers you to a login screen instead of to work.

Both of those are properties of the tab as a container, not of the startup setting. No amount of care in building the list touches either one, which is why the list tends to get rebuilt every few months without the morning getting better. A tab has no fixed position, no separate cookie jar, and no identity of its own. Moving each app into a window of its own is what changes those properties: position becomes stable, so apps are addressed by where they are rather than by reading titles, and each one keeps its own session. The model is described under Workspaces, and the wider set of behavior that follows from it, including notifications collected in one place, is listed under Features. Whether the services in your own morning routine are covered is the question that actually decides it, and that list is under Supported apps.

What to change first

Start by switching the startup group to the specific-pages option and putting exactly three entries in it, one per role, with the most-used one first. Live with three for a week before adding a fourth; most lists that grew to eight got there without anyone deciding to. If the residual problem turns out to be telling near-identical tabs apart rather than opening them, the next thing to look at is giving each app its own window, which is what SpaceDeck is built around.