Why Arc Was Loved by a Few but Never Became a Mainstream Browser

Can a product be beautiful enough to make designers constantly share screenshots, and clever enough to rethink how we use a browser, yet still fall short of becoming a successful mainstream product?

Arc once made me, and many other designers, genuinely excited. It made a product category that had barely changed in decades feel interesting again. But by 2025, Arc had entered maintenance mode and the team had moved on to Dia. What did Arc get wrong, and which of its ideas were still worth carrying forward?

I recently took Arc apart again and compared it with Dia, the browser built afterwards by the same team. My conclusion is that Arc’s problems went beyond having too many features or a steep learning curve.

Its visual identity invited one kind of user, while the product itself resonated with another. It asked people to learn too many new concepts before proving why those concepts mattered. Finally, it placed a product designed for a small group of committed power users inside a free, mass-market business model.

When those three problems compound, beautiful design can only do so much.

Why study a product that is already over?

Most product analyses focus on companies that are still growing, because success appears to offer the most useful lessons. Increasingly, though, I find finished products more revealing.

While a product is still fighting for the market, it is difficult to separate decisions that are genuinely working from problems that simply have not surfaced yet. Teams also keep adjusting the story, presenting every change as the next stage of the strategy.

Arc’s story is largely complete.

It was incubated inside Thrive Capital in 2019, opened publicly to macOS users in 2023, and raised roughly $128 million. After launch, it attracted intense interest from professional users. In the design community I was part of, Arc became one of those products everyone seemed to be discussing.

In May 2025, the company announced that Arc would enter maintenance mode and that its resources would move to Dia. In September 2025, Atlassian acquired the company for $610 million.

What makes the story especially useful is that the team did not disband. They carried their user data, technical knowledge and experience from Arc into another browser built from scratch.

Together, Arc and Dia form an unusually clean product experiment.

When the same team gets another attempt, what do they preserve? What do they remove? Where do they choose to invest their time and money again?

Those decisions are often more honest than any retrospective article, because the team has to place a real bet behind them.

Visit Arc’s website today and the first product you see is Dia.

A product using its own homepage to direct people towards its successor is a remarkably clear signal. The browser is still available, but the company has already moved on.

A product’s appearance is already choosing its users

Open Arc’s website and ignore the words for a moment. Its personality is immediately visible.

The design is warm, soft and artistic, with generous rounded corners, light animation and a slightly vintage, handmade texture. Its visual language belongs to the same broad family as Notion, Substack and Linktree.

These products often appeal to creators, individual users and people who enjoy shaping and organising their digital lives.

The communities where Arc actually became popular looked quite different. They were filled with engineers, designers, product managers and other heavy knowledge workers. Many discovered Arc through technology media, design communities or recommendations from colleagues.

These users cared about speed, keyboard shortcuts, multitasking and whether a browser could fit into a complicated professional workflow.

There was a subtle mismatch between the people Arc appeared to invite and the people who found the product most valuable.

Visual design alone will not decide whether someone adopts a product, but it answers an important question within the first few seconds:

“Was this made for someone like me?”

Before a user understands a single feature, the colour, typography, animation, information density and product screenshots have already started giving them an answer.

Linear offers a useful contrast.

Its interface is restrained, dense and deliberately cool, with the atmosphere of a professional development tool. It makes little effort to appear universally friendly. Instead, it communicates very clearly to engineers, designers and product managers that this is software made for serious team workflows.

Arc’s real users overlapped heavily with Linear’s target audience, yet the two products created almost opposite first impressions.

This is the first check I often use when analysing a product. I call it the Fit Audit.

It asks two simple questions:

What kind of person is your visual language inviting?

Is that the same person who is likely to stay, pay and use the product over time?

When there is a meaningful gap, a team eventually has to make a choice. It can change how the product presents itself, or it can redefine the customer it wants to serve. Ignoring the mismatch rarely works for long.

Every concept can be clear, and the product can still contain too many

Arc’s second problem was the number of new ideas it asked users to remember.

In a traditional browser, most people only need to understand two basic concepts: tabs and bookmarks.

Arc gradually introduced Profile, Space, Folder, Easel, Boost, Tab, Command Bar and Pinned Tab.

From a designer’s perspective, these concepts were not badly organised. Each had a clear purpose, and their relationships were reasonably coherent. Arc’s information architecture could even be described as elegant.

The problem is that a concept being understandable does not mean users want to remember it alongside seven others.

I call this the Entity Clarity Paradox.

A feature can be explained perfectly, supported by excellent documentation and represented clearly in the interface. Until it becomes part of a person’s habits, however, it remains another piece of mental overhead.

Spaces were one of Arc’s most important ideas. Users could create separate environments for work, personal life or individual projects, with each Space containing its own tabs, pinned pages and browsing state.

This is useful for people managing complicated workflows. According to figures shared by the Arc team, however, only around 5% to 12% of users adopted multiple Spaces. Calendar Preview reached just 0.4%.

Much of the differentiation the team spent years building never became part of most users’ behaviour.

That does not automatically make Spaces a bad feature.

It may simply mean Arc asked users to understand too many unfamiliar things before they had experienced enough value to justify the effort.

Every person learning a new product has a limited attention budget. The less familiar a concept is, the more of that budget it consumes. Arc effectively asked people to relearn the browser, while most users opened a browser because they wanted to continue whatever they were already doing.

Dia’s design supports this interpretation.

When the same team rebuilt the browser, it reduced Arc’s eight core concepts to three. Those three also resembled the mental model people already understood from Chrome.

The team reduced the number of features, while also reducing the amount of relearning required.

This matters for many products, particularly tools such as Notion, Airtable and Coda that depend on several interconnected concepts.

Design teams often ask whether each individual feature is clear enough. There is another question that matters just as much:

How many concepts must a new user understand before receiving their first meaningful piece of value?

The total number of concepts should be treated as a limited budget.

Arc stayed behind, but the Command Bar moved forward

Arc created many new concepts, and most of them stayed with Arc. One core interaction, however, was carried directly into Dia: the Command Bar.

At first glance, it looks like a more powerful address bar. Users can enter a URL, search for content, open a tab or execute a command.

Seen through the lens of modern AI products, its value is much larger.

The Command Bar creates a unified surface where users can express what they want to do. They can enter a website or ask a question. They can start a search, invoke AI, operate on a file or begin a voice interaction.

The system can then use browsing history, autocomplete and contextual suggestions to turn a vague intention into a specific action.

This pattern, combining human intent with system or AI assistance, is appearing across more products. Raycast, Linear, Notion and Slack are all moving in a similar direction.

Users no longer have to locate the correct feature first and then follow the path defined by the interface. Increasingly, they can tell the system what they want and let the product work out how to get there.

This may be the most useful lesson inside Arc.

A product can fail overall while still containing something extremely valuable. Sometimes the real asset is a particular interaction pattern, a technical capability, or a team that has learned how to solve a certain class of problem.

When Atlassian paid $610 million for The Browser Company, it was probably thinking beyond Arc as a conventional browser.

A more useful interpretation is that Atlassian acquired a new entry point into work.

Knowledge workers move constantly between Jira, Confluence, Slack, Google Docs and dozens of other SaaS tools. If the browser becomes the coordination layer above those tools, it stops functioning only as a window for opening webpages. It also becomes the place where work begins.

The Command Bar is the clearest surface for that idea.

For teams building products, this leads to a practical question:

If the entire product could retain only one core interaction, which one actually carries the user’s most important job?

The thing worth protecting may not be the complete shape of the product. It may be the underlying capability that solves the real problem.

A product move reveals what was genuinely valuable

Analysing Arc on its own was already interesting. Comparing it directly with Dia led me to a more practical method.

I call it the Moving List.

Imagine a company leaving one house and moving into another. Space and money are limited, so the team must decide what deserves to come along and what gets left behind.

The transition from Arc to Dia was exactly this kind of product move.

Dia kept the Command Bar, Split View, the sidebar and the way tabs move through their lifecycle.

The team left behind Spaces, Folders, Easel, and less mature AI features such as Tidy Tabs and Call Arc.

That list is one of the most honest evaluations the team ever produced.

The features that survived were doing important work for users. The features that disappeared may have been beautifully designed or conceptually interesting, but they did not create enough value to justify their learning cost.

This method applies far beyond browsers.

Any product that has gone through a major redesign, pivot, acquisition or second attempt can be studied in the same way.

Rather than listening only to how a team explains its past, look at what it chooses to keep funding when time and resources are limited.

In client work, I sometimes turn the Moving List into a more direct question:

If you started again today and could keep only 50% of the product, which features would survive?

Asking “Which features are not working?” usually produces polite and defensive answers. Every feature has a history, an investment and an internal advocate.

When a team has to remove half, priorities become much clearer. The features carrying real value and the ones that have become accumulated weight usually reveal themselves quickly.

The same number can support two opposite conclusions

There is one more issue in Arc’s story that is easy to miss.

Spaces reached only 5% to 12% of users. In his farewell letter, Arc CEO Josh Miller used this figure as evidence that the product’s central idea had not reached enough people and that the team needed to start again.

For a free product pursuing a mass market, this conclusion makes sense.

When only a small percentage of users adopt the main differentiating feature, most people are probably missing the product’s central value. Expanding the audience may increase downloads without improving retention.

If Arc had been designed from the beginning as a paid tool for professional users, however, the same number could mean something quite different.

Those 5% to 12% might have been Arc’s most valuable users. They understood Spaces and were willing to reorganise the way they worked around them. For a mass-market product, that group is too small. For a focused professional tool, it may represent a clear paying audience.

This leads me to a different interpretation of Arc.

Its biggest problem may have been placing a product that required people to change their habits inside a free business model chasing mass adoption.

Changing how someone uses a browser is expensive. The number of people willing to pay that learning cost will always be limited, but those users may also be willing to pay for a tool that genuinely improves their work.

Imagine Arc had positioned itself in 2023 as a paid browser for serious knowledge workers, charged $8 a month, and abandoned the ambition of becoming a browser for everyone.

Downloads would probably have fallen sharply. The people who remained, however, might have been a much stronger fit, allowing the product to go deeper for that audience instead of continually trying to lower the barrier and expand the market.

There is no guarantee that this approach would have succeeded. Vivaldi has served browser power users for more than a decade and still holds less than 1% market share. Focusing on a niche does not automatically produce a good business.

At the same time, Zen Browser attracted many former Arc users after Arc entered maintenance mode and continued to use a Spaces-like model. That suggests the concept itself still had genuine demand.

Spaces were not obviously a design mistake. Arc invited everyone in for free, while only serving a relatively small group exceptionally well.

Five questions Arc leaves for product teams

Remove Arc’s name from the story and the case still leaves five useful questions:

1. Is your visual language inviting your real target customer, or someone nearby who will never become a long-term user?

2. How many new concepts must a person understand before receiving value, and does that exceed the attention they are willing to spend?

3. Which core interaction carries the user’s most important task?

4. If you had to start again and keep only half the product, what would survive?

5. When you make a decision based on a metric, would the same number mean something different under another business model?

Arc did not become the next mass-market browser, but it still produced design ideas worth carrying forward.

It also gave me two practical ways to analyse other products.

The first is the Fit Audit, which examines whether the product’s visual language, concepts and intended audience genuinely align.

The second is the Moving List, which looks at what the next version keeps and removes in order to identify where the original product’s real value was concentrated.

Most teams eventually end up with a Moving List of their own.

The unfortunate part is that many companies only write it when the existing product can no longer continue. A better approach is to ask the question while there is still time to change direction:

If we had to begin again today, what would actually be worth bringing with us?

That question may take a team closer to the answer than adding one more feature.

---

If any of those questions landed without a clean answer, that gap is worth a closer look.

I write diagnoses like this one for other products: where your design is quietly serving the wrong outcome, what that is costing you, and what to change first. If you would like one for yours, email me at hi@bearliu.com.