8 Modern Examples of a Sidebar for 2026

You ship the page, open it on a laptop, and everything looks settled until the sidebar decisions start causing real layout problems. Filters steal width from the content. Secondary navigation works with a mouse but falls apart on a keyboard. The mobile version turns a helpful panel into a drawer that traps focus or covers the wrong content.

Sidebars are not decoration. They are layout and interaction primitives, and the wrong pattern creates problems fast.

Editorial practice has treated the sidebar as supporting content for years: short context, related facts, quotes, definitions, or companion material that helps the reader without pulling attention away from the main thread. Product UI follows the same rule. A sidebar should support the primary task, not compete with it.

This guide examines examples of a sidebar that hold up in production, with the trade-offs that usually get skipped in gallery posts. The goal is not just to show patterns, but to explain when each one fits, what accessibility requirements come with it, and how to implement it cleanly in Vue with modern headless components such as those from DOM Studio. Some sidebars should remain visible because orientation matters. Some should collapse because space matters more. Some behave like persistent navigation, while others work better as task-specific panels. Choosing correctly usually comes down to focus management, reading width, responsive behavior, and whether the sidebar content is truly secondary.

Table of Contents

• 1. Fixed Vertical Navigation Sidebar
  • When fixed beats clever
  • Vue and headless implementation notes
• 2. Collapsible Hamburger Menu Sidebar
  • What works on small screens
  • A practical Vue pattern
• 3. Nested Multi-Level Sidebar Navigation
  • Hierarchy without chaos
  • Vue example with controlled expansion
• 4. Content-Rich Sidebar Widgets and Panels
  • Support content, not clutter
  • A panel layout that stays readable
• 5. Sticky Floating Sidebar Panel
  • Where sticky shines
  • A Vue table of contents example
• 6. Slide-Out Drawer Sidebar Off-Canvas Pattern
  • Treat it like a modal, not a div
  • Vue drawer example
• 7. Contextual Dynamic Sidebar Context-Aware Content
  • The sidebar changes because the task changed
  • State, announcements, and transitions
• 8. Compact Icon-Only Sidebar Micro Sidebar
  • Space efficient, usability fragile
  • A safer compact pattern
• 8 Sidebar Styles Compared
• Choosing the Right Sidebar for Your Interface

1. Fixed Vertical Navigation Sidebar

Open a project dashboard, switch to billing, jump into alerts, then head back to settings. In apps with repeated section changes, a fixed sidebar still does the least harm because navigation stays in one place while the work area changes.

That stability is the whole point. Users build spatial memory fast. If the nav never shifts, they stop hunting and start moving.

When fixed beats clever

Use a fixed vertical sidebar for products with stable, high-frequency destinations. Dashboards, admin panels, documentation portals, issue trackers, and internal tools all fit this pattern well because people bounce between the same sections all day.

The trade-off is width. A sidebar that tries to hold every destination, filter, workspace switcher, and promo card usually turns into a second content column. Keep the primary nav tight, keep grouping obvious, and make the active state visible at a glance. If secondary actions matter, separate them visually instead of mixing them into the main route list.

A good fixed sidebar answers three questions immediately: where am I, what can I click, and what has keyboard focus?

Vue and headless implementation notes

Start with semantics. Use <nav aria-label="Primary"> for the container and aria-current="page" on the active route. Keep links for navigation and buttons for actions like expanding a group or pinning a panel. Mixing those roles creates keyboard and screen reader friction that shows up fast in production.

A minimal Vue setup looks like this:

<script setup>
import { computed } from 'vue'
import { useRoute } from 'vue-router'

const route = useRoute()

const items = [
  { label: 'Overview', to: '/overview', icon: 'home' },
  { label: 'Projects', to: '/projects', icon: 'folder' },
  { label: 'Alerts', to: '/alerts', icon: 'bell' },
  { label: 'Settings', to: '/settings', icon: 'cog' },
]

const isActive = (to) => route.path.startsWith(to)
</script>

<template>
  <nav aria-label="Primary" class="w-72 shrink-0 border-r bg-white">
    <ul class="p-3 space-y-1">
      <li v-for="item in items" :key="item.to">
        <RouterLink
          :to="item.to"
          class="flex items-center gap-3 rounded-md px-3 py-2 outline-none"
          :class="isActive(item.to) ? 'bg-neutral-100 font-medium' : 'hover:bg-neutral-50'"
          :aria-current="isActive(item.to) ? 'page' : undefined"
        >
          <span aria-hidden="true">{{ item.icon }}</span>
          <span>{{ item.label }}</span>
        </RouterLink>
      </li>
    </ul>
  </nav>
</template>

The code is simple. The hard part is getting the states right. Give each item a large enough hit area, preserve a visible focus ring, and do not rely on color alone for the active state. I usually pair background change with weight, icon treatment, or a left border so the current location still reads clearly in low contrast conditions.

If you want a production-ready starting point, a collapsible app shell for Vue layouts is a practical base because it already solves the shell structure and lets you focus on route logic and state styling.

One more implementation note matters here. Fixed does not mean permanent on every screen size. On narrower viewports, this pattern should switch to a drawer or collapsible variant before the content area becomes cramped. That breakpoint decision is usually more important than the sidebar styling itself.

2. Collapsible Hamburger Menu Sidebar

Some layouts need the space back. Analytics pages, code editors, and mobile views all benefit from a sidebar that can disappear until the user asks for it.

That doesn’t mean the pattern is automatically good. A collapsible sidebar works when the open and closed states are both legible. A bad one leaves users guessing whether navigation is hidden, partially available, or off-canvas.

What works on small screens

The hamburger trigger needs to stay easy to find. Put it in a stable position, reflect state with aria-expanded, and let Escape close the panel. On mobile, selecting a destination should usually close the sidebar too, because persistent overlays make the main screen feel trapped.

A related production lesson comes from Checkly’s redesign. Their team moved from a compact collapsed sidebar to one that always shows icons and labels, while the fully collapsed state hides the sidebar and brings it back on hover. The write-up is useful because it captures the trade-off between density and discoverability in Checkly’s sidebar redesign notes.

If people need to decode the navigation every time they reopen it, the collapsed state is saving space but costing throughput.

A practical Vue pattern

For teams that want a ready-made shell, DOM Studio’s collapsible sidebar shell is the kind of starting point that saves time because the interaction model is already thought through.

In Vue, keep state small and explicit:

<script setup>
import { ref } from 'vue'

const open = ref(false)
const close = () => (open.value = false)
</script>

<template>
  <button
    class="rounded-md px-3 py-2"
    aria-controls="app-sidebar"
    :aria-expanded="open ? 'true' : 'false'"
    @click="open = !open"
  >
    Menu
  </button>

  <aside
    id="app-sidebar"
    class="fixed inset-y-0 left-0 z-40 w-72 bg-white border-r transition-transform"
    :class="open ? 'translate-x-0' : '-translate-x-full'"
  >
    <nav aria-label="Mobile">
      <ul class="p-4 space-y-2">
        <li><RouterLink to="/dashboard" @click="close">Dashboard</RouterLink></li>
        <li><RouterLink to="/reports" @click="close">Reports</RouterLink></li>
        <li><RouterLink to="/settings" @click="close">Settings</RouterLink></li>
      </ul>
    </nav>
  </aside>
</template>

If you’re handling focus manually, move focus into the first interactive element when the menu opens, and return it to the trigger when it closes. That part gets skipped often, and keyboard users notice immediately.

3. Nested Multi-Level Sidebar Navigation

This is the enterprise pattern. AWS, Jira, WordPress admin, Linear, and Notion all use some version of nested navigation because one flat list can’t hold that much structure.

The mistake is assuming deeper hierarchy means more nesting. It usually means better information architecture. A multi-level sidebar should reveal structure, not dump it on the screen all at once.

Hierarchy without chaos

Parent items need clear affordances. Use chevrons, distinguish links from expanders, and auto-expand the path to the current page. Users shouldn’t land in a deep settings screen and see every ancestor collapsed.

For complex app navigation, a production pattern that holds up is to keep top-level destinations constrained and make children visually subordinate. A practical implementation guide recommends five to seven primary items, with sub-items reduced in type size and indented under their parent. That keeps hierarchy visible without making the whole panel noisy.

A few implementation rules matter more than fancy animation:

• Use buttons for expansion: Parent controls that open children should be <button> elements with aria-expanded.
• Expose the current route path: Mark the current page with aria-current="page" and keep ancestor groups open.
• Persist user intent: If a section is manually expanded, save that state locally so users don’t re-open the same tree every session.

Vue example with controlled expansion

DOM Studio’s app navigation builder is a useful reference if you need a structured pattern for docs, admin panels, or CMS navigation.

A simple recursive Vue approach can stay manageable:

<script setup>
import { reactive } from 'vue'

const expanded = reactive({
  settings: true,
  billing: false,
})

const toggle = (key) => {
  expanded[key] = !expanded[key]
}
</script>

<template>
  <nav aria-label="Settings navigation">
    <ul class="space-y-1">
      <li>
        <button
          class="flex w-full items-center justify-between rounded px-3 py-2"
          :aria-expanded="expanded.settings ? 'true' : 'false'"
          @click="toggle('settings')"
        >
          <span>Settings</span>
          <span aria-hidden="true">⌄</span>
        </button>

        <ul v-show="expanded.settings" class="ml-4 mt-1 space-y-1">
          <li><RouterLink to="/settings/profile">Profile</RouterLink></li>
          <li><RouterLink to="/settings/team">Team</RouterLink></li>
        </ul>
      </li>
    </ul>
  </nav>
</template>

Arrow key support is worth adding once the tree gets deep. Tab-only navigation still works, but directional movement feels much better in dense admin interfaces.

4. Content-Rich Sidebar Widgets and Panels

Not every sidebar is navigation. Some of the best examples of a sidebar are support panels that carry related content, filters, metadata, recommendations, or controls next to the main work area.

GitHub’s repository sidebar is a good example. It doesn’t try to replace the main page. It surfaces “About,” topics, links, and related metadata that support the primary content.

Support content, not clutter

Editorial guidance is surprisingly useful here. A sidebar is strongest when it complements the main text rather than carrying unrelated information, and it’s often used for fast-scanning facts, figures, or factoids in sidebar writing guidance for editorial layouts. That same principle applies to product interfaces. If the panel doesn’t help with the current task, move it somewhere else.

This pattern works well for:

• Documentation pages: Related links, page metadata, and version notes.
• Ecommerce views: Filters, product specs, shipping details, and comparison controls.
• Content platforms: Author cards, recommended posts, tags, and reading tools.

A panel layout that stays readable

Treat each widget as its own region with a heading. Don’t drop six unrelated controls into one gray box and call it a sidebar.

A clean Vue structure can be boring on purpose:

<aside aria-label="Related tools" class="w-80 space-y-4">
  <section class="rounded-lg border p-4">
    <h2 class="text-sm font-semibold">Filters</h2>
    <!-- filter controls -->
  </section>

  <section class="rounded-lg border p-4">
    <h2 class="text-sm font-semibold">Related Items</h2>
    <!-- recommendation list -->
  </section>

  <section class="rounded-lg border p-4">
    <h2 class="text-sm font-semibold">Saved Views</h2>
    <!-- saved state actions -->
  </section>
</aside>

The easiest way to break this pattern is to overload it. If users need to scroll past promo cards, decorative stats, and secondary widgets before reaching the one control they need, the sidebar has stopped supporting the page.

5. Sticky Floating Sidebar Panel

Sticky sidebars are common in docs, long-form articles, and knowledge bases because they keep orientation controls visible while the content scrolls. Wikipedia, MDN, Stripe docs, and technical blogs all rely on some version of this.

The sticky pattern is different from a fixed app sidebar. It starts in normal document flow, then sticks as the page moves. That makes it feel attached to the content rather than detached from it.

Where sticky shines

Use sticky for table of contents panels, reading progress tools, or filter groups that should remain nearby as people review long content. Don’t use it when the panel is taller than the viewport unless you’ve planned for internal scrolling.

There’s also a useful conceptual distinction here. In UX guidance, a sidebar often functions as a secondary information panel, and Texas A&M explicitly describes a sidebar “freestanding fact” as a compact element for quick-reference information. Navigation guidance also commonly places sidebars in the 200px to 300px width range for readable vertical menus. That’s a good mental model for sticky layouts too. Keep them compact and supportive.

Sticky works when it stays helpful. Once it starts blocking content or fighting the viewport, it becomes a floating annoyance.

A Vue table of contents example

A docs-style sticky panel doesn’t need much JavaScript unless you want active section highlighting. CSS handles most of the layout:

<template>
  <div class="grid grid-cols-[1fr_18rem] gap-8">
    <article class="min-w-0">
      <slot />
    </article>

    <aside class="self-start sticky top-6 max-h-[calc(100vh-3rem)] overflow-auto">
      <nav aria-label="Table of contents">
        <ul class="space-y-2 text-sm">
          <li><a href="#intro">Introduction</a></li>
          <li><a href="#setup">Setup</a></li>
          <li><a href="#api">API</a></li>
        </ul>
      </nav>
    </aside>
  </div>
</template>

Add IntersectionObserver if you want the active heading to update while users scroll. That’s where the pattern starts feeling polished without becoming overengineered.

6. Slide-Out Drawer Sidebar Off-Canvas Pattern

The off-canvas drawer is one of the most useful sidebar patterns because it protects screen space. It’s also one of the easiest to get wrong because developers treat it like a sliding panel instead of a temporary modal surface.

Shopify mobile navigation, X’s mobile menu, Slack on mobile, and map or chat interfaces all lean on drawers because the primary screen stays dominant until the user explicitly asks for more controls.

Treat it like a modal, not a div

If the drawer overlays the page, it needs modal behavior. Trap focus. Support Escape. Provide a close button. Prevent background scrolling. Make backdrop click behavior intentional, not accidental.

Most visual galleries fall short. A lot of “sidebar examples” content focuses on appearance while ignoring collapse logic, focus movement, keyboard handling, and responsive behavior. That gap matters because sidebars are layout and interaction patterns, not just menu skins, as noted in this critique of sidebar gallery content and implementation blind spots.

Vue drawer example

For production work, a purpose-built primitive is usually better than rolling your own. DOM Studio’s drawer component is the right kind of tool for this pattern because it handles the behavior developers usually under-specify.

A conceptual Vue implementation looks like this:

<script setup>
import { ref } from 'vue'

const open = ref(false)
</script>

<template>
  <button @click="open = true">Open filters</button>

  <div v-if="open" class="fixed inset-0 z-50">
    <div class="absolute inset-0 bg-black/40" @click="open = false"></div>

    <aside
      class="absolute right-0 top-0 h-full w-80 bg-white shadow-xl"
      role="dialog"
      aria-modal="true"
      aria-labelledby="drawer-title"
    >
      <div class="flex items-center justify-between border-b p-4">
        <h2 id="drawer-title" class="font-medium">Filters</h2>
        <button @click="open = false" aria-label="Close filters">✕</button>
      </div>
      <div class="p-4">
        <!-- filter content -->
      </div>
    </aside>
  </div>
</template>

If the drawer contains navigation, filters, or settings, the markup inside changes. The interaction contract doesn’t.

7. Contextual Dynamic Sidebar Context-Aware Content

This is the sidebar pattern most closely tied to workflow. Figma’s properties panel, Photoshop’s context-aware controls, VS Code’s tool panes, and issue detail panels in project tools all change based on what the user selected or what mode they’re in.

That’s powerful because the sidebar becomes task-specific. It’s risky because the interface can feel unstable if content changes too aggressively.

The sidebar changes because the task changed

A contextual sidebar should answer one question: what does the user need right now for the selected thing? If the answer changes, the sidebar can change too. If the answer doesn’t, keep it stable.

The good implementations share a few habits:

• They preserve layout consistency: The container stays put even when the contents swap.
• They announce meaningful changes: Screen reader users need feedback when a new panel or toolset replaces the old one.
• They avoid surprise resets: If someone edits a field, don’t discard in-progress state because selection changed accidentally.

State, announcements, and transitions

In Vue, Pinia is a natural fit because selected object state and panel mode often need to be shared between the canvas, main content, and sidebar.

A basic pattern:

<script setup>
import { computed } from 'vue'
import { useEditorStore } from '@/stores/editor'

const editor = useEditorStore()

const panelTitle = computed(() => {
  if (editor.selectedType === 'frame') return 'Frame properties'
  if (editor.selectedType === 'text') return 'Text properties'
  return 'Document settings'
})
</script>

<template>
  <aside class="w-80 border-l bg-white">
    <div class="border-b p-4">
      <h2>{{ panelTitle }}</h2>
      <p class="sr-only" aria-live="polite">{{ panelTitle }}</p>
    </div>

    <FramePanel v-if="editor.selectedType === 'frame'" />
    <TextPanel v-else-if="editor.selectedType === 'text'" />
    <DocumentPanel v-else />
  </aside>
</template>

The live region should be subtle. Announce panel changes, not every keystroke. Also keep keyboard focus stable unless the user explicitly opened a new subpanel. Forced focus jumps make contextual sidebars feel erratic fast.

8. Compact Icon-Only Sidebar Micro Sidebar

Icon-only sidebars look sharp in screenshots. VS Code’s activity bar, Discord’s server rail, compact Slack layouts, and some Figma surfaces all prove the pattern can work.

It also has the highest failure rate of any sidebar style because teams overestimate icon clarity and underestimate the cost of hidden labels.

Space efficient, usability fragile

The compact pattern is best when users are frequent and trained, the destination set is stable, and the app offers an easy way to expand to a labeled mode. Without that escape hatch, icon-only nav becomes memory work.

That’s why a lot of mature products pair compact mode with a fuller variant. The right takeaway isn’t “icons are enough.” It’s “icons are enough for users who already know the system and can recover quickly.”

“Compact” should describe width, not information loss.

A safer compact pattern

Every icon button needs an accessible name. Tooltips help sighted users, but they don’t replace labels for assistive tech. Add aria-label, keep active state visible, and provide a user setting that switches back to expanded mode.

A Vue micro-sidebar can stay lean:

<script setup>
const items = [
  { label: 'Home', icon: '⌂', to: '/home' },
  { label: 'Search', icon: '⌕', to: '/search' },
  { label: 'Notifications', icon: '⎋', to: '/notifications' },
]
</script>

<template>
  <nav aria-label="Primary" class="w-16 border-r bg-white">
    <ul class="flex flex-col items-center gap-2 py-3">
      <li v-for="item in items" :key="item.to">
        <RouterLink
          :to="item.to"
          class="flex h-10 w-10 items-center justify-center rounded-md hover:bg-neutral-100"
          :aria-label="item.label"
        >
          <span aria-hidden="true">{{ item.icon }}</span>
        </RouterLink>
      </li>
    </ul>
  </nav>
</template>

If you add hover-reveal labels, don’t make them hover-only. Keyboard users need the same label exposure on focus. And if the compact rail starts collecting badges, status dots, and nested actions, it’s no longer compact. It’s overloaded.

8 Sidebar Styles Compared

Choosing the Right Sidebar for Your Interface

The right sidebar depends on what the interface is trying to protect. If the product needs constant movement between major sections, a fixed vertical nav is still hard to beat. If the main canvas or content area needs room, a collapsible or drawer pattern usually serves the workflow better. If the page is long and reference-heavy, sticky support panels keep orientation close without pulling users away from the document.

That sounds obvious, but most sidebar mistakes come from solving the wrong problem. Teams pick an icon-only rail because it looks modern, when the product needs labeled destinations. They pick a nested enterprise tree for an app that only has a handful of top-level screens. Or they bolt widgets into a sidebar because there’s empty space, then wonder why the interface feels busy.

Accessibility should drive the implementation details, not get added after the layout is approved. Navigation sidebars need semantic landmarks, visible focus, and active state clarity. Drawer sidebars need focus trapping, Escape handling, and scroll locking. Contextual sidebars need careful announcements and stable focus behavior when content changes. Those details are what separate a polished app shell from a pretty mockup.

There’s also a broader product question behind all examples of a sidebar: is the sidebar primary, secondary, or temporary? A primary sidebar anchors the app. A secondary sidebar supports the main content. A temporary sidebar appears on demand and then gets out of the way. Once you classify it correctly, a lot of implementation choices become easier. Width, collapse behavior, keyboard model, and responsive treatment all follow from that role.

For Vue teams, headless primitives are the fastest route to getting this right. You keep control over markup, styling, and state, but you avoid rewriting the same ARIA and interaction logic for every new shell, drawer, and panel. That’s especially useful when your design system needs multiple sidebar patterns across the same product. A marketing site may need a content-rich sidebar. The app needs fixed navigation. Mobile needs a drawer. The admin area might need nested navigation. They shouldn’t all be hand-built from scratch.

Build the sidebar around the task, not the empty edge of the screen. Keep the main content dominant. Make state visible. Test with a keyboard before you call it done. Then test it on a narrow viewport, because that’s where weak sidebar decisions show up first.

---

If you’re building production-grade sidebars in Vue, DOM Studio gives you a strong foundation without locking you into a rigid design system. Its headless primitives and Vue layer are a good fit for fixed navigation, drawers, collapsible shells, contextual panels, and the awkward accessibility details that usually eat implementation time.