Tabs (UI)
A row of labels that switch between alternative views of the same object, showing one panel at a time.
Tabs are a row of labels that switch between alternative views of the same object, showing one panel at a time. The important word is alternative: tabs imply that these are different ways of looking at one thing, and that seeing two at once would not make sense.
That single implication decides most of the cases where tabs are the wrong component. Content that is sequential is a wizard. Content somebody needs side by side is a split view. Content that is simply separate topics is an accordion.
Tabs against the alternatives
| Shows | Right for | Runs out at | |
|---|---|---|---|
| Tabs | One panel of several | Alternative views of one object | About five items |
| Accordion | Any number open | Independent topics of uneven length | Scales widely |
| Sidebar navigation | One section | Many destinations, hierarchical | Scales widely |
| Stepper | One step, in order | A sequence with a beginning and an end | Sequences longer than about six |
| Segmented control | One of a few filters | Switching a view's mode, not its content | Three or four |
The tab and segmented-control distinction is worth holding: tabs change what you are looking at, a segmented control changes how you are looking at the same thing.
Details that decide whether tabs work
The active tab in the URL. Without it the tab is unlinkable from documentation, lost on refresh, and invisible to the back button. Support articles end up saying "click the third tab", which stops being true the moment the tabs change.

Labels that distinguish. One or two words naming the content, in the user's vocabulary. Tabs called Overview, Details and Information are three words for the same thing.
Stable order. Reordering tabs by recency or usage means people cannot build muscle memory, which is most of what makes a tabbed interface fast for regular users.
No badge inflation. A count on a tab is useful when it means something needs attention. On every tab it becomes decoration.
Panels that keep their state. Returning to a tab should restore the filter, scroll position and half-typed input, or the component punishes moving between views.
Where tabs fail in B2B
Too many, so they wrap. A second row of tabs reads as a different control, and the relationship between the rows is unclear. Wrapping is a signal that the structure needs a level, not that the row needs more room.
Content that hides work in progress. Tabbing away from a form with unsaved changes and back is a common way to lose work. Either preserve it or warn.
Permission-dependent tabs. A viewer meeting a tab whose panel is entirely disabled learns nothing. Omit it, or explain what would grant access.
Loading on every switch. Tabs feel instant when the data is already there and sluggish when each switch is a request. Prefetching the likely next panel is usually worth it in a product people move around in all day.
Nested tabs. Tabs inside a tab panel are almost always a structural failure. The second level usually wanted to be a sidebar or a separate page.
Tabs and the structure underneath
Tabs are frequently added to a screen that has outgrown itself, which makes them a useful diagnostic.
A record page that acquires a fifth and sixth tab is usually telling you that the record has become several things. The question worth asking before adding another is whether these are views of one object or a group of related objects that happen to share a page.
Two signals that the structure rather than the component needs work. Tabs that nobody switches to: an analytics look at tab usage often shows one tab carrying almost all traffic, which means the others are hidden pages rather than alternative views. And tabs holding unrelated things, where Settings sits beside Activity beside Billing, which is a small navigation system wearing a tab row.
In both cases the resolution is information architecture rather than a better tab component.
In practice
A customer record has five tabs: Details, Activity, Billing, Notes, Settings. It works well until support articles start being written about it.
The articles cannot link to a tab, because the URL does not change, so they say "open the customer and click Billing". Then Billing is renamed to Plan, and every article is quietly wrong. Meanwhile customers report losing notes, because typing in Notes and switching to Activity discards the draft.
Two fixes, neither visual. The active tab goes in the URL, so articles link directly and the back button behaves. Panel state persists across switches, so the draft survives.
The tabs themselves were the right component throughout. What was missing was everything around them.
Where teams get it wrong
- No URL state. Unlinkable, and lost on refresh.
- Wrapping to a second row. Read as two controls, not one.
- Discarding panel state. Switching views loses work.
- Nested tabs. A structure that needed another shape.
- Labels that do not distinguish. Overview, Details and Information.
- Divs instead of a real tablist. Keyboard and screen-reader behaviour silently absent.
Learn more
Frequently Asked Questions
Related terms