Originally published at: Do You Use It? Revisiting Websites with Windows, Bookmarks, Tabs, and Pinned Tabs - TidBITS
Reading the responses to last week’s Do You Use It? poll about browser tab management caused me to think a lot harder about why tabs exist at all, the motivation behind the development of pinned tabs, and how pinned tabs vary so much between Safari, Chrome, Firefox, and Arc.
Overall, I wasn’t surprised by the results, which show that about half of TidBITS readers don’t experience tab overload at all, with only 1–10 tabs open because they always close tabs as soon as they’re done. However, the other half of the respondents suffer from increasing levels of tab overload, with 14% of respondents saying that they have over 100 tabs open. I’m not quite that bad anymore, but testing browsers other than Arc caused me to slip back into bad habits, such that I had well over 50 tabs open when I answered the poll. For me and many other people, tabs are pages to read later, tasks to complete, or simple reminders to do something. That may not be the best way to accomplish those goals, but it requires no additional effort and is thus hard to pass up.
Other than Arc users, TidBITS readers don’t use pinned tabs heavily, with 54% saying they have none. Another 31% said they have either 1–5 or 6–10, suggesting that they use Chrome or Firefox, which support pinned tabs but have significant limitations. Once someone says they have more than 20 pinned tabs, I suspect they’re using Safari or Arc, which provide far more capable pinned tab behavior. Why do so few people use pinned tabs? Some undoubtedly would benefit but don’t understand them, whereas others may use the Web too casually for pinned tabs to be helpful.
I was surprised by the number of people who commented that they still open new windows rather than use tabs, and by some of the more unusual strategies for revisiting websites later. But those comments were what caused me to think more deeply about what tabs and pinned tabs are meant to do, to wonder where they came from, and to research the evolution of browser navigational aids.
There’s no one right way to browse the Web, but looking at the history of where these navigational aids came from and what they were designed to do might help you think about how you interact with online information. We’ll start with multiple windows, move on to bookmarks, browser history, and search engines, take a look at tabs, and then focus on pinned tabs.
1992: Browsing in Multiple Windows
Imagine it’s 1992, and someone has just given you the Erwise Web browser. Pretty much all it can do is display pages, triggered either by typing a URL manually or following a link on a page. It doesn’t even have a Back button.
On the one hand, it would be recognizable, and you’d be able to use it. On the other hand, you would immediately encounter a problem: how do you maintain the state of the current page while navigating to another one, much as you might open multiple books at once? (Remember, this is 1992; books are your touchstone.) The initial solution in Erwise was to allow multiple windows, which was in the interface vernacular of the time, given that Erwise was built for the X Window System.
Subsequent browsers made opening multiple windows easier, to the point where MacWWW, the first Web browser for the Mac, opened a new window every time you clicked a link to navigate to a new page. I was reminded of this by my coverage of MacWWW in the first edition of Internet Starter Kit for Macintosh, though that rather harsh coverage embarrassed me when I met its developer, Robert Cailliau; see “20 Years of the World Wide Web in the Public Domain,” 1 May 2013.)
I can’t find any research suggesting how prevalent multiple window use was in the early days, but given the glacially slow speeds of Internet connections in the 1990s (remember, we’re talking about modems), it was undoubtedly a common behavior. I distinctly remember opening pages in the background so they could load while I finished reading the current one. It’s an interface paradigm that persists to this day—you can still configure Safari so that clicks on links to different sites open in new windows.
There’s even a modern throwback to those days: by default, Arc opens links from other apps in a standalone Little Arc window that’s meant to be read quickly and either closed or moved to Arc’s main window. I often find Little Arc windows on a second display a handy way to keep reference articles in view while writing in my main Arc window.
1993: Revisiting Sites Using Bookmarks, Browser History, and Search Engines
Being able to open multiple windows is one thing, but how do you get back to a page you saw yesterday, or last week? In 1993, NCSA Mosaic introduced bookmarks, which provided shortcuts for revisiting websites. (It also reportedly introduced the Back and Forward buttons, though my coverage of MacWWW suggests that it also had a Back control.) Instead of recording URLs outside the browser and entering them manually, a bookmark (then called a hotlist and later called a favorite by some browsers) was simply a URL and optional name stored within and accessible by the browser.
As the Web grew, bookmarks became essential navigational aids and have barely changed since. Even the interface surrounding bookmarks hasn’t changed much—all you can do is organize them in nested folders. That’s not a criticism; even though we’ve seen changes in how bookmarks are presented and synced between browsers, there isn’t much call for improvement.
Mosaic also introduced the first history window, which showed recently visited pages in a list, as a sort of automatically created bookmark list. It was improved upon in various ways by subsequent browsers, but perhaps the most important enhancement was the ability of the address bar to suggest pages from the history when the user types part of the name or URL. We spend a lot of time visiting the same sites over and over again, and browser history makes that easier.
Of course, many people don’t bother creating bookmarks or using other shortcuts and instead rely on a Web directory or search engine. That became a common approach once browsers could initiate Google searches from the address bar. Users could simply type into the address bar and get bookmarks, history, and search suggestions all at once, as shown in Safari below. And, as we’ll see next, tabs.
2001: Tabs Take Over from Windows
It takes quite a few years to move beyond using multiple windows, but eventually, tabs appear. The first Web browser to feature tabs was Adam Stiles’s NetCaptor in 1998, as acknowledged by David Hyatt, who implemented tabbed browsing in the Mozilla Web browser (an open source version of Netscape Navigator) in 2001, as well as Chimera (later Camino) and Phoenix (later Firefox), before joining Apple to work on Safari.
Hyatt believed that tabbed browsing was only for power users since novice users just browse from page to page and don’t need multiple views of Web content. Presumably, novice users also don’t open multiple windows. Nevertheless, tabs caught on in a big way because they made parallel browsing faster, easier, and cleaner. No longer did you have to shuffle between multiple, likely overlapping windows; instead, you could click a file folder-like tab at the top of the browser window.
A study by Patrick Dubroy found that, by 2010, users (in an admittedly small group) had a strong preference for tabs over windows, citing the improved user experience. In 2015, The Nielsen Norman Group’s research found that younger users heavily use tabs for “page parking,” where they rapidly open multiple tabs to capture pages they plan to revisit later. Page parking works well for separating the cognitively separate tasks of hunting for and digesting information. Tabs also serve as memory aids because you can remember that information is in a tab rather than devoting more brain space to the information.
The key aspect of all these tab uses was what Dubroy called “revisitation.” In essence, tabs are all about revisiting a previously loaded page. The main difference between tabs (or previously loaded windows) and more conventional other revisitation mechanisms—the Back button, bookmarks, browser history, and Web searches—is that tabs (and windows) don’t require the page to be reloaded. From a performance standpoint, today’s fast Internet connections make that less of an issue, but as the Web becomes more of an app platform, constant reloading is more problematic. Regardless, I hope you see that everything we’ve talked about so far is about revisitation.
2010: Pinned Tabs Support Web Apps and Always-Open Sites
Roughly another decade elapses before we get pinned tabs, which are developed to support yet another level of revisitation. For much of the early days of the Web, pages were largely static repositories of information. Even pages that did change regularly, such as the home pages for publications, did so only multiple times per day. However, once fast-moving social media sites became popular, and as Web technologies enabled full-fledged apps like Gmail and Google Docs, browser makers realized that people wanted some tabs to be available at all times to make checking or working in them easier. In essence, that’s all a pinned tab is—a persistent tab that’s designed to resist accidental closure.
Google first introduced pinned tabs in 2010 with Chrome 5, and a year later, Mozilla even referred to its first implementation as “App Tabs” in Firefox 4. Apple was late to the game, adding pinned tabs only in 2015 with Safari 9. (Michael Cohen covered Safari’s pinned tabs and other revisitation technologies in “Bookmarks, Top Sites, and More: Finding Your Way Back in Safari,” 26 August 2016.) Although pinned tabs in these three apps are fairly similar, there are key differences. Arc, of course, didn’t come out until 2023, and its pinned tabs are dramatically different (see “Arc Will Change the Way You Work on the Web,” 1 May 2023).
It has become apparent from the discussion following our Do You Use It? poll that many people don’t understand pinned tabs. To some extent, that’s likely because many TidBITS readers developed their browsing habits decades ago—quite a few people also commented that they preferred windows to tabs, which I’ll bet isn’t true of anyone born this century.
However, once I explored how pinned tabs worked in the major browsers, I realized that they differ in important ways, which I’m sure adds to the confusion that may dissuade many users. This inconsistency may also explain why Arc’s rethinking of pinned tabs has been attractive primarily to users for whom quick website revisitation is paramount.
How Browsers Differ in Handling Pinned Tabs
Although the pinned tab concept is broadly similar across modern browsers, the specifics vary considerably between Chrome, Safari, Firefox, and Arc, particularly in visual treatment, behavior, and integration with other organizational features. Let me explain how the browsers are similar or different across what I believe are the main goals of pinned tabs.
Pinned Tabs Should Be Easy to Access
Chrome (shown below), Firefox, and Safari display pinned tabs at the top left of the horizontal tab bar, with standard tabs to the right. In 2022, Safari 16 introduced the option to display tabs in a vertical sidebar as well, with pinned tabs appearing at the top of each tab group.
Arc, which was in development before Safari 16’s release, has always stored its tabs in a vertical sidebar, with pinned tabs in a section on top and standard tabs below. In 2025, Firefox added an option to make tabs vertical as well, with pinned tabs appearing as favicons at the top (shown below). Unfortunately, Firefox can display only one row of pinned tabs—add too many and you’ll have to scroll awkwardly within that row. It amazes me that Mozilla’s developers didn’t allow multiple rows of pinned tabs.
My take: Given that screens are wider than they are tall, making vertical screen real estate more precious, the vertical tab interfaces in Arc, Safari, and Firefox provide the best interface for anyone with more than a handful of tabs of any sort, but Firefox’s inability to show more than one row of pinned tabs at once is a serious misstep.
Pinned Tabs Should Be Easy to Identify
In their horizontal tab bars, Chrome, Firefox, and Safari reduce pinned tabs to favicon-only slivers with no visible titles. This minimalist presentation is space-efficient, but it becomes hard to parse unless there are only a few pinned tabs and their favicons are distinctive. For unknown reasons, Safari adjusts its behavior slightly for pinned tabs in tab groups, displaying as much of the page title as fits until more tabs force them to shrink to their favicons (shown below).
Switching to a vertical tab bar helps, at least in Arc (shown below) and Safari, which show pinned tab titles, offering much more context. Arc even lets you rename pinned tabs. Oddly, Firefox still shrinks pinned tabs to favicons in its vertical sidebar. (To be fair, Arc also relies solely on favicons for its “favorites,” which are a small number of special pinned tabs that appear at the top of all workspaces.)
My take: For anyone with more than a few tabs, the difficulty of identifying sites by tiny 16×16-pixel favicons makes the vertical sidebars in Arc and Safari preferable since they display full site titles.
Pinned Tabs Should Be Difficult to Remove
Chrome, Safari, and Firefox all remove the close button from pinned tabs so a misclick doesn’t accidentally remove the pinned tab—you must Control-click the tab or use a menu to remove it. Arc does display a close button on hover in the sidebar, though an accidental removal can be reversed with Undo.
Pressing Command-W while a pinned tab is active does nothing in Firefox, which is good. In Safari and Arc, it closes that view of the pinned tab, but leaves the pinned tab in place, which is very good. In Chrome, pressing Command-W closes the pinned tab and removes it, which is seriously wrong.
Similarly, if you click the window’s red close button in Chrome, you lose all your pinned tabs, whereas, in an Arc or Safari window, pinned tabs reappear when you open a new window. Firefox is in between—if you have only one window with pinned tabs open, you can close it with the red close button and reopen it without losing pinned tabs, but if you have two windows with different pinned tabs open, closing one destroys its pinned tabs.
My take: Arc and Safari work correctly here—if you go to the effort of pinning tabs, inadvertently closing a window shouldn’t cause you to lose them. The key is that pinned tabs in Arc and Safari aren’t tied to the window, whereas they are in Chrome and Firefox.
Pinned Tabs Should Persist Across Sessions
If you quit and relaunch your Web browser, you shouldn’t lose any pinned tabs. Happily, that’s the case for all four browsers, though you might have to enable a setting to restore windows and tabs from the previous session.
My take: This is the one area where all browsers handle pinned tabs correctly! All the browsers can maintain pinned tabs through launches.
Pinned Tabs Should Be Global
As I noted, Chrome and Firefox attach their pinned tabs to specific windows, so they don’t appear when you open a new window. The main argument for that approach is that you could have multiple windows with different pinned tabs, but given how easy it is to close a window inadvertently and lose those pinned tabs, I’m not a fan.
Pinned tabs in Safari are either global or specific to a tab group—either way, they’re always accessible. Arc’s model is more like Safari’s tab groups, with pinned tabs being specific to each workspace; its favorites are global.
My take: Again, Safari and Arc have it right here. Since the point of pinned tabs is to make it easy to revisit sites, they should be as persistent as possible, and decoupling them from easily closed windows supports that.
Pinned Tabs Should Be Easy to Rearrange
All four browsers let you drag pinned tabs to reorder them within their pinned region. Arc also allows folders and nesting within its sidebar, offering a more structured organizational model than the linear row used by the others.
My take: Arc takes the win here by virtue of providing folders and letting you rename pinned tabs. Safari leads the other browsers by providing titles that make it easier to see what you’re working with when you rearrange the pinned tabs.
Pinned Tabs Should Integrate with Grouping Features
Tab groups are a relatively new browser feature that enables you to collect related tabs into groups to reduce tab overload. Pinned tabs in Chrome and Firefox are entirely separate from the tab grouping system, whereas Safari allows you to pin tabs within tab groups, and Arc collects its pinned tabs within workspaces.
My take: Safari and Arc are on the right track here. Why prevent users from including pinned tabs in groups? Chrome and Firefox are probably dragged down by how their pinned tabs exist only at the window level.
Pinned Tabs Should Remember Their Original URLs
Let’s say you pin a tab for the TidBITS home page. You then click around in the TidBITS site and end up on some random article before quitting for the day. In my opinion, when you come back to your browser the next day, clicking your pinned TidBITS tab should load the TidBITS home page. Unfortunately, that’s not what happens in Chrome, Safari, and Firefox, all of which leave pinned tabs showing the last page visited rather than the original URL they were pinned with.
Arc behaves differently. While you’re working, you can switch among Arc’s pinned tabs, and they’ll reflect wherever you’ve navigated within that site, just like the others. However, if a pinned tab remains inactive for long enough, Arc unloads its current state (which also reduces memory usage) and reverts to the original pinned URL, discarding any navigation history since the tab was pinned.
In essence, Arc’s pinned tabs act like bookmarks when you first click them in a session, but like tabs for the remainder of the session. It’s the best of both worlds and explains why Arc users have so many pinned tabs. You might think of them as “tabmarks” that combine the persistent nature of bookmarks with the immediate access of tabs.
My take: Arc has the right idea here, and other browsers should copy it. There’s no reason to juggle bookmarks and tabs when a well-implemented system like Arc’s can combine them so effectively.
Pinned Tabs Should Sync Across Devices
If you’re going to create pinned tabs for your most frequently revisited sites, wouldn’t you want to have access to them on all your devices? Although Chrome and Firefox can sync bookmarks and open tabs, they don’t sync pinned tabs, likely due to the way their pinned tabs are attached to windows.
In contrast, Safari and Arc do sync their pinned tabs along with everything else, which is easy because of how their pinned tabs are contained in tab groups or workspaces.
My take: Safari and Arc have it right here, and this is yet another reason why pinned tabs should be independent of windows.
Which Revisitation Technologies Should You Use?
I realize this is a lot—I didn’t anticipate that I’d venture so far down the rabbit hole. However, let me see if I can wrap things up by providing advice for a few user types:
- Casual users: These users maintain minimal or no pinned tabs, have basic bookmarks for essential sites like banking, email, news, and shopping, and open very few regular tabs at once due to a strong preference for one thing at a time. They rely heavily on address bar suggestions and search engines. They benefit from simplified browser interfaces and don’t need anything beyond the basic features of any browser.
- Online shoppers: With a handful of pinned tabs for favorite retailers and deal sites, and a moderate number of bookmarks for stores and wishlists, these users experience heavy tab usage during shopping sessions, followed by mass closure. They rely heavily on browser history and Web searches from the address bar. Any browser should work well for these users, but there’s little reason to go beyond Safari, Chrome, or Firefox.
- News junkies: These users maintain some pinned tabs for daily-check sites like news and forums, extensive bookmark collections, and numerous regular tabs that serve as a “read later” system. They could use any browser but might benefit from Safari’s tab groups or Arc’s automatic tab cleanup to avoid information overload.
- Researchers and academics: Numerous pinned tabs for core work sites like Gmail, Slack, research databases, and university portals help these users stay productive, along with extensive bookmark folders organized by project, client, course, or research topic. They may also juggle multiple regular tabs for active research and literature reviews, and would greatly benefit from the superior pinned tab implementations in Arc and Safari, which include folders and workspace features.
- Journalists and content creators: These users keep pinned tabs for publishing platforms, social media sites, and analytics tools, with bookmarks for inspiration sources and competitor sites. They also have plenty of regular tabs open for active research and reference. As with researchers, they would be well served by Safari’s tab groups and Arc’s workspaces.
- IT pros and app workers: Heavily reliant on numerous pinned tabs for Web apps like Google Docs, Notion, monitoring dashboards, and admin panels, these users don’t need traditional bookmarks as much since they work primarily in applications. They maintain only a few regular tabs since most of their work happens in pinned Web apps, and they often use multiple browser profiles or workspaces to separate different client environments. Arc’s “tabmark” behavior and workspaces would be perfect for their workflow.
Regardless of these suggestions, I hope this exploration has either convinced you that your current approach is perfect for your needs or given you some ideas for how you can change things up to eliminate aspects of your workflow that annoy you.
