{"slug":"tabs","meta":{"title":"Tabs","slug":"tabs","kind":"pattern","summary":"One record or screen split into a few named sections, only one visible at a time, with the section in the URL so a tab can be linked to.","problem":"A record page grows past a screenful, so everything is stacked vertically and the person scrolls past four sections they do not care about to reach the one they do — every single time.","family":["orient","inspect"],"data_shape":["record"],"principles":["progressive-disclosure","orientation"],"interaction":["navigation","disclosure"],"density":"low","complexity":"low","status":"stable","visibility":"public","use_when":["The content splits into a few named sections people think of as separate.","Different people, or the same person at different times, want different sections.","Each section is substantial enough to be worth a screen."],"avoid_when":["People need to compare across sections. Tabs make that impossible by design.","There are more than about six sections, where the tab bar becomes navigation.","One tab is opened 95% of the time — that content should just be the page.","The sections are short. Stacking them costs one scroll and no clicks."],"alternatives":[{"slug":"collapsible-section","when":"People need several sections at once, or the sections are short."},{"slug":"persistent-navigation","when":"The sections are really separate screens with their own workflows."}],"ask_leo":"Split this record page into tabs.\n\n- Use between two and six tabs, named as nouns a person would say — Details,\n  Line items, History, Files. Not verbs, and not internal model names.\n- The first tab is what most people came for, and it is the default.\n- Put the active tab in the URL so a tab can be bookmarked, shared and\n  restored after a reload or after leaving and coming back.\n- Mark the active tab with weight and a rule, not colour alone.\n- Show a count on a tab when the count is decision-relevant — \"Files (0)\"\n  saves a click, and \"Comments (3)\" earns one.\n- Keep the record's identity header ABOVE the tab bar, so it stays visible on\n  every tab. The tabs switch the detail, never the identity.\n- Do not hide anything urgent behind a non-default tab. If a person must act\n  on it, it belongs on the first screen or in the header.\n","related":[{"title":"Progressive Disclosure for Dense Detail Pages","url":"/cookbook/progressive-disclosure-detail-page","summary":"The implementation guide, including when tabs beat collapsing."},{"title":"Object Identity Header","url":"/patterns/object-identity-header","summary":"What stays above the tab bar, on every tab."}]},"body":"## Anatomy\n\n```\nINVOICE #1043 · Riverside Fit-Out · Overdue 12d      ← header: always visible\n──────────────────────────────────────────────────\n Details │ Line items (7) │ History │ Files (0)\n ═══════\n   ↑ active: weight + rule, and in the URL as ?tab=details\n```\n\n- **The identity header sits above the tabs.** If switching tabs changes who you\n  are looking at, they were not tabs, they were navigation.\n- **The active tab is in the URL.** Without it, every link to the record lands on\n  the default tab and every reload loses the person's place.\n- **Counts where they decide something.** \"(0)\" is as useful as \"(7)\" — it saves\n  the click.\n\n## Why it works\n\nTabs are progressive disclosure with an unusually good door: the door is\nlabelled, permanently visible, and shows how many other doors exist. Compared\nwith collapsed sections, tabs make the *whole shape* of the record visible from\nany one view.\n\nThey also let one page serve people with different jobs. A salesperson wants\nDetails, finance wants Line items, support wants History. Stacked vertically,\neach of them scrolls past the other two.\n\n## The trade\n\nTabs make **comparison across sections impossible**. You cannot see line items\nand history at once, by construction. That is the entire cost, and it is why\ntabs are wrong whenever the job requires holding two sections in view — there,\n[collapsible sections](/patterns/collapsible-section) or a two-column layout are\ncorrect.\n\nThe second cost is hiding. Anything behind a non-default tab is invisible to\nsomeone who does not go looking, so a tab is the wrong home for anything urgent.\nThe count on the tab is the mitigation, and it only works for things that can be\ncounted.\n\n## Getting it wrong\n\n- **Tabs as navigation.** Six tabs where each is a different object with its own\n  workflow — that is a nav bar with the wrong styling.\n- **No URL state**, so tabs cannot be linked and reload resets them.\n- **Something urgent on tab four.** Nobody sees it, and the record looks fine.\n- **A tab bar that scrolls sideways**, which hides the existence of tabs — the\n  one thing the pattern is supposed to make visible.\n- **The identity header inside the tab**, so it disappears when you switch and\n  you lose track of what you are looking at.\n\n## Exemplars\n\n**Stripe's customer page** keeps the identity and balance fixed and tabs the\ndetail beneath — payments, subscriptions, invoices — which is the correct\ndivision: one subject, several bodies of detail.\n\n**GitHub repository tabs** (Code, Issues, Pull requests, Actions) sit right at\nthe boundary between tabs and navigation, and their URL-per-tab is what makes\nthem work at all: every tab is a linkable destination.\n\nThe extractable rule: **tabs divide the detail, never the subject.** If\nswitching a tab changes what the page is about, you needed navigation instead.\n"}