Chrome pinned tabs disappear: what unpins them between sessions

Eight tabs sat pinned on the left of the tab strip for weeks. Mail, calendar, a ticket queue, two admin panels. This morning the strip opens empty, or holds a single new tab page, and the icons are gone. Nothing was uninstalled and no setting was touched, which is exactly why the loss feels arbitrary.

It is not arbitrary. Pinning is a property of a tab inside a session, not a permanent list stored somewhere separate, and a small number of events decide whether that session comes back. Knowing which of those events happened narrows a vague problem to one place to look.

What pinning stores, and what it does not

Chrome's own description of the feature is deliberately small. Pinning is described as a right-click action on the tab, and the result is stated in one sentence: pinned tabs are smaller and only show the site's icon. Unpinning is the same right-click with the opposite command. There is no separate list of pinned sites in settings, no export, and no page that displays them independently of the window they live in.

That absence is the whole shape of the problem. A bookmark is a stored record that survives everything short of deleting it. A pinned tab is an attribute attached to a tab that happens to be open right now. When the set of open tabs is reconstructed, pinned tabs return. When it is not reconstructed, they do not, and there is nothing left behind to reconstruct them from.

Two consequences follow. Pinned tabs belong to a window, so a second window opened later starts with none of them. And pinned tabs belong to a profile, since each profile keeps its own browsing state, so opening a different profile shows a different strip. Someone who works in two profiles sees their pinned set appear and vanish depending on which window is in front, with no event having occurred at all.

The practical reading is that pinning is a layout convenience, not storage. Anything that must survive independently of a session belongs in a bookmark folder as well, and that duplication is the cheapest insurance available here.

The startup setting decides whether they come back

The single most common cause is a startup choice that was made once and forgotten. Chrome offers three options for what opens when it launches, found under Settings and then On startup: Open the New Tab page, Continue where you left off, and Open a specific page or set of pages.

Only the second of those reconstructs the previous session. Google describes it plainly:

You can tell Chrome to re-open the same pages you were looking at when you quit. Your cookies and data are saved, so any websites you were logged into before open again. Source: support.google.com

With Open the New Tab page selected, every quit discards the session by design, and pinned tabs go with it. With Open a specific page or set of pages selected, the listed addresses open as ordinary tabs, unpinned, which produces a confusing middle state: the right sites appear, in the wrong form, at full width with titles showing.

This explains the most common timing pattern. A machine that keeps its pinned tabs for days and loses them after a restart, an update, or a long weekend is a machine that never quits Chrome in normal use. The setting was always wrong. It only became visible when the process finally ended.

Checking this takes seconds and settles the question before anything else is investigated. If the startup choice is not Continue where you left off, that is the answer, and the remaining sections are about narrower cases.

Quitting is not the same as closing windows

On macOS the distinction between closing a window and quitting an application creates a second pattern. Closing the last window leaves Chrome running, and a new window opened afterwards is a fresh window with no pinned tabs, even though the session was never ended. The previous window is not gone in the sense that matters for recovery, but it is gone from view.

Pressing Command + W repeatedly to clear the screen produces exactly this. So does closing a window that held the pinned set while a second window, opened for something unrelated, stays open. Chrome treats the closed window as a closed window, and the window that remains keeps its own strip.

An abnormal exit behaves differently again. When Chrome ends without a clean shutdown, the session data on disk may be incomplete, and the recovery path is whatever the startup setting allows rather than a guarantee. A crash on a machine set to open the new tab page leaves nothing to restore. The same crash on a machine set to continue where it left off usually restores everything, pinned state included.

There is a related case worth naming because it looks like corruption. A profile that is heavily used and then opened on a second machine, or restored from a backup, can carry an older session file than expected. The strip that appears is a real previous session, just not the most recent one. Sites that were pinned in the last week are absent while sites pinned months ago are present.

Memory Saver makes a present tab look absent

A tab that has been unloaded to save memory is still there, but it stops behaving like a live page, and for a pinned tab reduced to a favicon the difference is easy to misread. Chrome's performance features deactivate tabs that have not been used, and the documented behavior on return is automatic: when an inactive tab is accessed, it reloads.

The visual signal is subtle. Chrome offers an inactive tabs appearance option, and when it is on, the tab icon is shown inside a ring. A pinned tab is already nothing but an icon, so a ring around it is the only difference between a loaded and an unloaded state. The site is not missing. It is asleep, and a click wakes it.

Where this genuinely causes loss is on reload. A page that held an unsaved draft, a filled form, or a state that only existed in the browser loses that state when the tab is deactivated and reloaded. The tab survives and the work inside it does not, which is often what people mean when they say a pinned tab disappeared.

Chrome allows specific sites to be exempted. Under Settings and then Performance there is a list labelled Always keep these sites active, with an Add button that accepts currently open tabs or a manually entered pattern. Anything pinned because it must stay live, such as a queue that streams updates or a page holding a long-running form, belongs on that list. Reference pages that merely need to be within reach do not, and exempting everything defeats the purpose of the feature.

Sync carries almost everything except this

The assumption that a signed-in profile restores pinned tabs on a new machine is reasonable and wrong. The list of data types Chrome syncs is published, and it covers bookmarks, reading list, passwords, payment info, extensions, web apps, and settings and preferences, with tabs and browsing history available as separate items once signed in.

When you sign in to Chrome, on all your devices, you can find your info like: Bookmarks, Reading list, Passwords, Payment info, Identity docs, contact and travel info, and more, Extensions, Web apps, Settings and preferences. You can also sync your tabs and browsing history to your Google Account once you've signed in to Chrome. Source: support.google.com

Synced tabs are exposed as a list of what is open elsewhere, which is a different thing from reconstructing a window with the same tabs pinned in the same order. A new Mac signed into the same account arrives with every bookmark and password in place and an empty tab strip. That is the documented outcome, not a fault.

The workaround is to stop depending on the session for something that needs to persist. A bookmark folder containing the same eight sites can be opened as a group at any time, on any machine, and rebuilt into a pinned set in under a minute. It is manual, and it is the only method here that does not depend on a session file surviving.

What happened	Why the pinned tabs went	Where to look
Gone after every restart	Startup is set to open the new tab page	Settings, On startup
Right sites return but unpinned	Startup is set to a specific list of pages	Settings, On startup
Gone after closing the last window	The window ended while Chrome kept running	Reopen with Command + Shift + T
Icons present but pages blank until clicked	The tab was deactivated to save memory	Settings, Performance
Empty strip on a second machine	Sync does not carry the pinned state	Rebuild from a bookmark folder
Different set depending on the window	A second profile is in front	The profile icon at the top right

Getting a lost set back

Immediately after the loss, the fastest route is the reopen shortcut. Chrome documents Command + Shift + T on Mac for bringing back a tab or a window that was just closed, and pressing it repeatedly walks backwards through the recently closed list. A window restored this way returns with its pinned tabs pinned, because the window itself is what is being restored.

Once other browsing has happened, the recently closed list has moved on. History still holds the addresses, which is enough to rebuild by hand, though it will not restore the order or the pinned state. Sorting by the day the set was last seen and opening the sites that appear every morning reconstructs most of it.

After a rebuild, the durable step is to make the same set exist somewhere that is not a session. Creating a bookmark folder from the current window, then setting startup to continue where it left off, covers both the accidental case and the deliberate one. Doing only the second leaves the crash case unprotected.

When the pinned strip is doing a job it was not built for

A row of favicons standing in for mail, chat, a ticket queue, and two admin panels is a workspace being assembled out of a feature meant to keep a few tabs from scrolling away. It works until a quit, an update, a second window, or a profile switch, and then the whole arrangement has to be rebuilt by hand.

The reason it is fragile is structural. Every one of those sites shares one window, one session file, and one set of cookies, so any event that affects the window affects all of them at once. Giving each web app its own window, inside a browser built to hold them, removes the shared point of failure: the set is configuration rather than session state, and it does not depend on how the last shutdown went. That model is described in Workspaces, and the services that can be treated this way are listed in Supported apps. For anyone comparing that approach against running several browser windows, the differences are set out in Compared with Wavebox.

What to change first

Open Settings, look at On startup, and set it to continue where it left off. Then create a bookmark folder from the current window so the same set exists outside the session. If the pinned strip has become the place where a day's worth of applications live, SpaceDeck keeps that arrangement as configuration instead of as something a quit can erase.