Skip to main content

Documentation Index

Fetch the complete documentation index at: https://learn.mintlify.com/llms.txt

Use this file to discover all available pages before exploring further.

Tabs let users switch between versions of content on the same page. Used well, they keep documentation concise and targeted. Used poorly, they force users to click through variations they don’t need and make it hard to find the information they need. Before adding tabs, identify if content varies by user context like operating system, language, or authentication method, or if it’s content that different users need to compare like different authentication methods.

​
What are tabs good for?

Tabs are the right tool when your content covers the same topic but the implementation differs based on something about the user’s setup.
Example of tabs
<Tabs>
  <Tab title="npm">
    ```bash
    npm install @mintlify/sdk
    ```
  </Tab>
  <Tab title="yarn">
    ```bash
    yarn add @mintlify/sdk
    ```
  </Tab>
  <Tab title="pnpm">
    ```bash
    pnpm add @mintlify/sdk
    ```
  </Tab>
</Tabs>
A user installing with npm doesn’t need to read the yarn instructions. Tabs let them skip directly to what applies to them without having to read through the other instructions. Other good uses:
  • Operating system variations (macOS, Windows, Linux)
  • SDK language examples (Python, Node, Ruby)
  • Authentication methods when the choice was already made earlier in setup
  • Separate content for two distinct user roles (admin versus user)

​
Tab sync

When tabs across a page share the same title, selecting one syncs all of them. For example, if a user selects Python in one tab group, every other tab group on the page with a Python tab title switches automatically. To sync, tab titles must match exactly. Python, python, and Python 3 don’t sync.
Tab groups that sync and ones that don't
{/* These two groups sync because the titles match */}
<Tabs>
  <Tab title="Python">...</Tab>
  <Tab title="Node.js">...</Tab>
</Tabs>

<Tabs>
  <Tab title="Python">...</Tab>
  <Tab title="Node.js">...</Tab>
</Tabs>

{/* These don't sync */}
<Tabs>
  <Tab title="Python 3">...</Tab>
  <Tab title="NodeJS">...</Tab>
</Tabs>
If you want a tab group to operate independently of other tab groups, add sync={false}:
Example of a tab group with syncing disabled
<Tabs sync={false}>
  <Tab title="npm">...</Tab>
  <Tab title="yarn">...</Tab>
  <Tab title="pnpm">...</Tab>
</Tabs>

​
When not to use tabs

Don’t use tabs to compare options. If users need to read both tabs to make a decision, tabs aren’t appropriate. They make it hard to compare since users must switch back and forth between tabs. Use a table, side-by-side columns, or sequential sections instead. Don’t bury a recommendation in tabs. If one option is right for 90% of users, putting it side by side with the 10% case implies they’re equal. State the recommendation before the tabs. Don’t use tabs to manage page length. A page that’s too long needs to be split into multiple pages or reorganized, not tabbed. Tabs should never hide content that users require. Don’t duplicate tabs that your site navigation already handles. If your documentation already separates admin and user content into different sections, adding role-based tabs inside a page signals that the page is in the wrong section. If you have more than four or five tab options, consider a <CodeGroup> with the dropdown prop instead. Long tab rows get crowded on mobile and can be hard to read.
Next up: Code groups for multi-language examples — How code groups handle the specific case of showing the same code in multiple languages.