Tabs in Confluence: Native Layout Tabs vs Tabs Macros Compared
Tabs are the layout workhorse of product pages, API references, and comparison docs: they let one page hold three versions of the truth (per environment, per plan, per language) without tripling the scroll length. Confluence's answer to tabs has changed over the years, so this page sorts out what exists today and which to use when.
What Confluence gives you natively
Confluence Cloud now ships page tabs: when you create a page using a tabs-capable template (or add tabs to an existing page), each tab is backed by a child page rendered inside the parent.
What this buys you:
- No app required — works in every Cloud instance
- Per-tab permissions — because tabs are real pages, space permissions apply per tab
- Direct links and history — each tab has its own URL and version history
- Scales well — a tab can hold a full page's worth of content
The trade-offs:
- Structural weight. Tabs-as-child-pages is an opinionated structure; a quick 3-tab comparison means creating 3 pages plus the parent.
- Content-level tabs are missing. You can't drop a small tabbed panel inside a section of a page — it's a whole-page layout decision.
- Limited styling. The tab bar looks like Confluence; per-tab colors, images, and layouts aren't options.
What a tabs macro adds
For tabbed content — panels inside a page, styled to match the page's design — Marketplace tabs macros fill the gap. The Tabs macro in Content Formatting Macros & Page Builder for Confluence works like this:
- Up to 8 tabs per macro, each with a title, optional heading and description, and rich-text content
- Per-tab imagery — image, background color, image fit/position/size, and overlay for building product-style panels
- Layout control — tab position (top, left, or right), alignment, underline, and hover effects
- Styles and presets — line, pills, or card styles; presets like Image Left, Image Top, and Image Background for landing-page-like sections
Multiple tabs macros can sit on one page — a common pattern is one per major section, each grouping 3–4 variants (per plan, per environment, per audience).
Choosing per page
| Situation | Best fit |
|---|---|
| Documentation with permission differences per section | Native tabs (child-page permissions) |
| Product page with styled panels and images | Tabs macro |
| Quick comparison of CLI flags / API versions inside a doc | Tabs macro (lighter than 3 child pages) |
| Multi-language docs where each tab is a full translation | Native tabs |
| Landing-page-style sections (pricing, features) | Tabs macro with presets |
| Content that must be one page for export/search simplicity | Tabs macro (single page body) |
The rule of thumb: native tabs when tabs are pages; tabs macro when tabs are content.
A note on migrations
If you're coming from Server/Data Center, old third-party tabs macros stored content in a single page body. Moving to Cloud native tabs means promoting each tab's content into child pages — worth doing when permissions or per-tab history matter, and worth avoiding when the tabs are small content fragments (then a Cloud tabs macro keeps the original shape).
Related reading
- Expand macro for Confluence — the accordion cousin: hiding content vertically instead of horizontally
- How to build FAQ sections in Confluence — structured Q&A without tab sprawl
- Content Formatting Macros & Page Builder — tabs, expand, panels, and 20 more macros