Figma section header components

A section header is the label on one block of a screen, plus whatever controls act on that block. A team list with a search field above it. A billing table with a date range switcher.

The tab row that flips a settings panel between General, Members, and Plans without touching the rest of the page. The 12 variants here cover those cases with three action types and an optional row of tabs.

One step down from the page title

Scope is what separates the three header components in this kit. The page header owns the screen and its primary action. The section header owns one block on that screen. The card header owns a single card.

Get this wrong and you end up with two buttons on one screen both styled as the primary action, leaving the user to work out which is real.

A practical test: if the action changes the whole page, it goes at the top. If it only adds a row to the table underneath, it belongs here.

Buttons, a button group, or a search field

The Type property decides what sits at the right end of the header.

Buttons is the default pair, usually a secondary next to a primary. Button group is a segmented control for switching the view without leaving the page: 12 months against 30 days, list against board. Search is an input that filters the section in place.

The choice mostly comes down to whether the block has one dataset with several views, one dataset too long to scan, or something to create. If a section needs a combination this header does not cover, button groups and filters exist as their own sets and drop into the same slot.

Tabs add exactly 64px

With Tabs off, the desktop header is 67px tall at 1,216px wide. Turn tabs on and it becomes 131px. The tab row costs 64px, and that is the entire price in layout terms, but the interaction cost runs higher.

Tabs hide content, and the default tab collects most of the attention while everything behind the others gets less, which Nielsen Norman Group's guidance on tabs is worth reading before you add a fourth or a fifth. Use tabs when the views are genuine alternatives, not when you have run out of vertical space.

In production the row needs arrow key navigation and proper roles, set out in the W3C tabs pattern. For a tab row on its own, with more styles and sizes, there is a separate set of horizontal tabs.

Mobile at 343px, plus a smaller label

The mobile variants are drawn at 343px, which is a 375px screen minus 16px of padding on each side. Without tabs they run 139px, or 143px with the search field, because the title, the supporting line, and the controls each take a full row. With tabs they reach 195px.

Alongside the header sits a smaller section label component in two sizes, 40px and 48px tall, or 72px and 80px once an action is attached, for the moments when a block needs a name but not the full apparatus. Everything is drawn twice in the file, light and dark.

The pattern is easiest to judge in context: the settings page and dashboard examples use section headers to break long screens into blocks that can be scanned in any order, which is what they are for.

The same section headers exist in code. Untitled UI React section headers are open source, built with Tailwind CSS and React Aria, with tab semantics and keyboard handling already done.