20 CSS Responsive Navbar Designs

A responsive navbar is the page-level navigation chrome that adapts its layout across viewport sizes — desktop typically shows full horizontal links, tablet usually trims utility links, and mobile collapses behind a hamburger, bottom tab bar, or off-canvas drawer. Decision rule: content-heavy site (marketing, docs, blog) → sticky shrink-on-scroll navbar (Demo #06) + animated underline tabs (#04) or pill highlight (#05). App / SaaS dashboard → fixed sidebar drawer (#03) or vertical rail (#18) for primary nav with a compact top bar for context. E-commerce → mega menu dropdown (#02) for deep category trees + a glassmorphism (#01) or split two-tone (#09) brand bar. Long-read article / docs → reading-progress breadcrumb (#08) + scroll-spy section highlight (#20). Mobile-first product → bottom tab bar (#10) plus a top brand bar. Premium / luxury → centered logo (#12), neon dark (#07), or floating island (#16). Every demo here is scoped .nav-NN so you can copy multiple patterns into the same page without style collisions while you decide.

Cumulative Layout Shift (CLS) is one of three Core Web Vitals Google measures, and shrinking headers are a notorious cause. The trap: a tall hero header that suddenly compresses to a thin sticky bar at scrollY > 100 ALSO removes its document-flow height, causing every below-fold element to jump up by the delta. The fix: keep the header at a constant height on the layout (e.g. height: 80px) and shrink only the internal elements (logo size, padding, font-size) via a .is-shrunk class. Demo #06 (Scroll-Aware Shrink Navbar) ships this pattern: the outer nav stays at fixed height: 80px sticky-positioned, an IntersectionObserver toggles .is-shrunk on scroll, and the children animate their own dimensions inside the constant outer box. Modern alternative (Chrome 115+, Safari 26+): use scroll-driven animations with animation-timeline: scroll(root) instead of an IntersectionObserver — zero JavaScript, GPU-accelerated, no main-thread scroll listener. The CSS export in Demo #06 includes both implementations so you can pick based on browser support targets.

Pure CSS works for: dropdown menus (use :hover on desktop and :focus-within for keyboard), hamburger toggles (checkbox-hack with hidden input + sibling selectors), animated underlines (:hover + ::after pseudo), pill highlights (:has() in modern browsers or radio-button state machines), and most static layout patterns. JavaScript is required for: scroll-spy active highlighting (you need IntersectionObserver or scroll-driven animations with the new animation-timeline: scroll()), reading-progress bars that track exact scroll percentage, focus traps inside fullscreen overlay menus (WCAG 2.4.3 requires it for modal-like UI), Escape-key dismissal, and persistent state across page navigations. We ship 14 pure-CSS demos and 6 with a vanilla-JS snippet (no framework, no library, no jQuery) for the patterns that genuinely require it. Each JS snippet is 5–30 lines and lives in the demo's JS tab — copy alongside the CSS tab and drop into a <script> at the bottom of your page.

Most 'CSS mega menu' tutorials stop at :hover opens / :hover closes. That breaks keyboard users (Tab can't enter the panel because hover is mouse-only) and screen-reader users (the open/closed state isn't announced). The WCAG 2.2 / Section 508 / EU EAA accessible pattern requires: (1) :focus-within opens the panel on keyboard focus (works alongside :hover), (2) aria-expanded="true|false" on the parent trigger announces the state, (3) aria-haspopup="menu" tells screen readers there's a submenu, (4) Escape key closes the panel and returns focus to the trigger, (5) arrow-key navigation within the panel (Roving tabindex pattern), (6) the panel itself uses role="menu" with children as role="menuitem". Demo #02 (CSS Mega Menu Dropdown Navbar) ships the full pattern, and Demo #14 (Full-Screen Overlay Menu) implements a complete focus trap with focus return on close. Tools to audit: axe DevTools, Lighthouse, WAVE, NVDA + screen reader testing — every one of these will catch the missing aria-expanded that 90% of tutorial mega menus ship without.

Tailwind UI ($300+/year): ships pre-styled navbar Catalyst / Catalyst Pro components, beautiful but you're licensed not owning the design. shadcn/ui (free, React + Radix): does NOT ship a dedicated navbar; you compose one from NavigationMenu + DropdownMenu primitives. Material UI / MUI: ships <AppBar> with Material aesthetics and ~95kb bundle cost. Chakra UI: composable but you assemble nav from Flex + Menu primitives. Ant Design: ships <Menu mode='horizontal'> with enterprise-friendly defaults. Bootstrap 5: ships .navbar + .navbar-collapse with the canonical mobile collapse pattern. This generator vs. all of the above: these are EDITABLE source CSS / HTML / JS — copy what you like and customize freely (brand color, exact corner radius, specific hover behaviour). Use the component libraries when you want a complete design system in 30 seconds. Use these demos when you want fine control or when you're building your own design system from scratch and need the source CSS to inform your token decisions. Drop any demo's CSS into our converter to see the Tailwind utility-class equivalent.

The classic approach uses IntersectionObserver to watch each section enter/leave the viewport and toggle .is-active on the matching nav link. Demo #20 (CSS Scroll Spy Active Highlight Navbar) ships this pattern in ~15 lines of vanilla JS: const obs = new IntersectionObserver(entries => entries.forEach(e => { if (e.isIntersecting) document.querySelector(a[href="#${e.target.id}"]).classList.add('is-active'); }), { threshold: 0.5 }); then iterate all section[id] elements and observe them. The IntersectionObserver is GPU-friendly and doesn't run on every scroll frame like a manual window.scroll listener would. Modern alternative (Chrome 115+ / Edge 115+ / Opera 101+; partial Safari 26+ / Firefox 134+): CSS scroll-driven animations via animation-timeline: view() let you do scroll-spy entirely in CSS — animate --active custom property as each section scrolls through the viewport, then use :has() + @scope to flip the matching nav link's color. Zero JavaScript. Demo #20's CSS includes a commented-out scroll-driven-animations version next to the IO implementation.

Decision rule by app type. Bottom tab bar (Demo #10): 3–5 primary destinations the user switches between FREQUENTLY (Instagram, Twitter/X, TikTok pattern). One-tap access; thumbs reach the bottom; ALWAYS visible. Best for: social apps, e-commerce shopping (Home / Search / Cart / Account), B2C SaaS. Hamburger menu (see our CSS Hamburger Menus collection): 6–15+ destinations, secondary tasks, settings, admin pages. Best for: content sites, docs, blogs, admin dashboards. Fullscreen overlay menu (Demo #14): editorial / portfolio / agency sites where the navigation transition itself is part of the brand expression. Beautiful but ALWAYS adds an interaction step before the user reaches content. Off-canvas sidebar drawer (Demo #03): SaaS dashboards with deep but-not-frequently-accessed nav (admin tools, project switcher, settings hierarchy). Combines well with a small persistent top bar carrying context (page title, user avatar). Most production apps use a HYBRID: bottom tab bar for the 4 most-used destinations + a hamburger or drawer for everything else. The Twitter / Instagram / Threads apps all do this. Demos #03, #10, and #14 in this collection are designed to layer together — copy multiple onto the same page and gate them by viewport width via @media queries.

CLS is one of three Core Web Vitals — Google measures it on every Lighthouse / PageSpeed Insights audit and ranks pages with high CLS lower. Common navbar causes: (1) Web font swap: if the navbar uses a custom font, fallback font has different metrics → text reflows → CLS spike. Fix: use font-display: optional or font-display: swap + size-adjust in @font-face. (2) Shrink-on-scroll without fixed height: the navbar's height changes on scroll → entire page-below-navbar shifts up. Fix described in FAQ #2 — keep outer navbar height constant, shrink only inner elements. (3) Logo image with no dimensions: image loads asynchronously and reflows the layout. Fix: width + height attributes on <img>, or aspect-ratio: 4/1 on the logo container. (4) Mobile hamburger toggle uses display: none → block: the menu's opening shifts content. Fix: use transform: translateY() + height: 100dvh on an overlay (no layout impact). (5) Sticky positioning glitch: position: sticky on a navbar inside an overflow: hidden parent silently fails on some browsers. Fix: move sticky to a direct child of <body> and ensure no ancestor clips overflow. Tools to verify: Chrome DevTools Performance Insights, Lighthouse, Core Web Vitals report in Google Search Console, axe DevTools, WebPageTest filmstrip.

Generally NO for desktop, conditionally YES for mobile. Why mobile-yes: thumbs naturally rest near the bottom of phone screens — a top-positioned navigation requires reaching up (especially on 6.5"+ devices). The iOS Human Interface Guidelines, Android Material 3, and the Threads / Instagram / TikTok / Pinterest apps all use bottom tabs because of this ergonomic. Why desktop-no: on a 1440px monitor, the bottom of the screen is below the user's natural reading position — they have to scroll their eyes / mouse there. Desktop conventions place primary nav at top because the user is already there. The hybrid pattern (Demo #10 ships this): bottom tab bar visible at max-width: 720px via media query, hidden at desktop where a conventional top navbar takes over. Add padding-bottom: 72px to main on mobile so the fixed bottom bar doesn't overlap content. Use 3–5 tabs maximum (more than 5 reduces tap accuracy). Each tab needs a 24×24px icon minimum + label below ≤ 12px. Mark the active tab with both color AND a small indicator (icon dot, top border, or fill) — color alone fails WCAG 1.4.1 (Use of Color).

Yes — all 20 navbars are MIT licensed and free for personal and commercial use, including in client projects, SaaS products, design systems, and open-source libraries. The MIT license requires only that you keep the copyright notice if you redistribute the source code itself; in shipped production HTML / CSS that you've adapted, no visible attribution is needed. If you ship one as part of an open-source UI library, a one-line credit pointing to https://codefronts.com is appreciated but not legally required. Accessibility: every demo uses semantic <nav> + <ul>/<li> structure, aria-current="page" on the active link, aria-label on icon-only buttons, visible :focus-visible rings, aria-expanded on toggles, focus trap on modal-like overlays, Escape-key dismissal, and proper landmark roles so screen-reader users navigate them correctly. Continuous animations honour prefers-reduced-motion: reduce. The collection ships ready to pass WCAG 2.2 AA — verify with axe DevTools, Lighthouse, or WAVE before shipping to EU EAA / US Section 508 / UK Equality Act audits.