Should sections of my web app open in browser tabs or in tabs I draw myself?

The question that decides it: does state need to be shared between the open sections?

If each section is independent — a document, a record, a report — browser tabs are almost always right. You inherit an enormous amount for free: back and forward, bookmarks, history, open in new tab, restore after crash, drag a tab to a second monitor, and a tab management model every user already knows.

If the sections share live state — a running process, a websocket, an in-memory dataset, an editor with cross-references — in-app tabs start to earn their cost, because coordinating that across browser tabs is genuinely hard and often means rebuilding it anyway.

Everything else in this decision is secondary to that one question.

From watching people use both: the strongest argument for browser tabs is that users already have a system for managing them.

People have habits — pinning, grouping, muting, a second window on another screen, tab search. All of that applies to your app for free if you use real tabs, and none of it applies if you draw your own. Power users in particular tend to be annoyed by in-app tabs precisely because their existing workflow stops working.

The counter-observation is that less experienced users sometimes lose track of which browser tab holds which part of your app, especially if your titles are not distinct. That is worth fixing directly — set a specific document title per section — rather than treating it as a reason to build your own tab strip.

One middle option that often gets missed: a split or panel layout instead of tabs at all.

If the reason people want several sections open is to compare or reference between them, tabs are the wrong shape entirely — only one is visible at a time. Two panes side by side answers the actual need better than either tab design, and it sidesteps the whole question.

Worth checking what people are really doing before building either tab system.

The thing people underestimate is how much you are signing up to reimplement with in-app tabs. The list is longer than it looks:

• Middle-click and control-click to open in a new tab
• Reordering by dragging
• Closing with the keyboard, and reopening the last closed one
• Overflow when there are more tabs than width
• Restoring the set after a reload
• Deep linking to a specific tab
• What the browser back button does now

That last one is the killer. Users press back expecting to leave the current section and instead leave your entire app, or you intercept it and now back means something different inside your product than everywhere else on their computer.

In-app tabs are a real feature with a real budget, not a styling choice.