25 CSS Button Groups

A button group is a set of related interactive buttons rendered as a single visual unit — a segmented control (single-select), a toggle group (multi-select), a split button (primary + menu), an icon toolbar (parallel actions), a pill radio group (filter chips), a floating action button with fan-out (radial menu), or a Web3 wallet-connect grid (provider picker). The pattern signals that the buttons share a context, axis of meaning, or mutually-exclusive state. Use a group when: (1) the buttons share a data target — a pricing toggle picks between Monthly and Yearly, an ecommerce filter chip row picks category tags, an editor toolbar formats the same selected text; (2) selection is mutually exclusive with a visible active state — iOS-style segmented controls, single-select alignment picker, view mode switcher (list / grid / kanban); (3) actions are related but distinct — a split button offers a primary action plus a menu of variants, an email client shows Reply / Reply All / Forward / Archive as parallel choices; (4) the group needs keyboard-single-tab semantics — roving tabindex on a toolbar, radio group navigation for exclusive selection, arrow-key movement between icon buttons. Use separate buttons instead when the actions are unrelated, have different priorities, or belong to different screens. This collection ships 25 button groups covering every canonical variant plus modern high-CPM verticals (SaaS pricing, fintech dashboards, Web3 wallet connect, AI model selection, healthcare, legal, insurance, real estate).

SaaS marketing and product surfaces — Demo 04 (CSS Pricing Toggle with Monthly / Yearly Switch) is the workhorse for every SaaS pricing page (Stripe / Linear / Vercel / Cron / Superhuman ship variants of this); Demo 18 (Multi-Action Button Group with Gradient Flow Progress) fits SaaS onboarding wizards; Demo 20 (Vertical Button Stack with 3D Hover Depth) is a dashboard action column pattern. Fintech and banking — Demo 24 (Action Button Row with Radar Shockwave Click Feedback) is a trading-platform action bar; Demo 12 (Segmented Control with Liquid Mercury Thumb) is the fintech payment-method picker Stripe and Ramp use; Demo 25 (Date-Range Preset Button Group with Cursor-Following Glow) is an analytics date-range picker. Web3 and crypto — Demo 10 (Wallet Connect Button Grid for Web3 Sign-In) covers MetaMask / WalletConnect / Coinbase / Rainbow / Phantom provider pickers exactly the way OpenSea, Blur, and Uniswap ship them; Demo 14 (Multi-Select Chip Buttons with Acid Glow) is the NFT filter chip pattern; Demo 22 (Filter Button Group with RGB-Split Glitch) matches Web3-native aesthetic. AI and LLM tooling — Demo 11 (AI Model Selector Button Group with Provider Badges) is the GPT / Claude / Gemini / Mistral model picker that every LLM playground UI ships. Ecommerce and product listing — Demo 14 (Multi-Select Chip Buttons) doubles as ecommerce filter tags; Demo 08 (Pill Radio Button Group with Sliding Indicator) is a category filter. Editor and productivity tooling — Demo 07 (Icon Button Group for Toolbar Actions) is the Docs / Notion / Linear toolbar pattern; Demo 09 (Toggle Button Group with Radio Inputs) is the single-select alignment group (left / center / right / justify); Demo 16 (Format Toggle Button Group with Conic Fill) is a text-formatting toolbar. Healthcare, legal, insurance — Demo 08 fits appointment-type selectors, legal practice-area filter chips, insurance quote preset pickers; Demo 09 works for HIPAA-compliant filter groups where accessibility is regulated. Real estate — Demo 04 or Demo 09 for the rent / buy toggle every Zillow-style portal uses. Streaming — Demo 04 for the subscription-tier picker (Basic / Standard / Premium). Every demo is hand-coded CSS with zero dependencies and a WCAG 2.2 AA accessibility floor. Copy the HTML + CSS panels, drop into any stack, ship.

Four honest trade-offs. Bundle cost — Radix UI's ToggleGroup, RadioGroup, and DropdownMenu primitives ship as React components with their own state management (~35KB gzip once you include React DOM). shadcn/ui wraps Radix with additional Tailwind styling (adds another layer). Aceternity and Magic UI ship their own React components on top of Framer Motion (60KB+). Headless UI (Tailwind Labs) is Vue / React only. Every button group in this collection is either 100% pure CSS or CSS + under 40 lines of vanilla JavaScript — the entire collection totals under 20KB uncompressed of framework-free code. Framework lock-in — Radix, shadcn, Aceternity, Headless UI all require React (or Vue for Headless UI). These 25 demos drop into any stack (Astro, Next.js, SvelteKit, Vue, Solid, Qwik, plain HTML, Rails ERB, Django, Laravel Blade, WordPress themes) with zero adaptation. The HTML + CSS + optional JS panels are the whole delivery. License and cost — Aceternity Pro is $299+/year for their full component collection. Magic UI Pro is a subscription. shadcn and Radix are free but tie you to their specific dependency tree. Every demo here is MIT licensed, free forever, no attribution required (though a link back to codefronts.com is always appreciated). Accessibility floor — Radix and Headless UI are accessibility-first (they're what shadcn is built on), and they get this part right. But if you don't need the primitive-composition model — if you just want a pricing toggle, an icon toolbar, a wallet connect grid — the accessibility contract in this collection matches Radix's: real interactive elements (button, input radio, input checkbox, details / summary), keyboard navigation with roving tabindex where appropriate, focus-visible rings, aria-pressed / aria-current / aria-expanded / aria-label where relevant, prefers-reduced-motion guards throughout, and 44×44px minimum touch targets (WCAG 2.5.5). That said — if you're already on Radix and want composable primitives with your own styling, Radix is the correct choice. If you want a copy-paste solution that ships to production in five minutes with no npm install, this collection is faster. Tailwind users: every demo's CSS translates cleanly — display:grid + grid-template-columns:repeat(3,1fr) maps to grid grid-cols-3; border-radius:999px maps to rounded-full; backdrop-filter:blur() maps to backdrop-blur. Named @keyframes and @property registrations belong in tailwind.config.js under extend.keyframes + extend.animation, or a small @layer utilities block.

Two production approaches ship in this collection. Approach 1 — native <details> / <summary> (Demo 06): the primary action is a <button>; the dropdown trigger is a <summary> inside a <details> element. When the user clicks the summary, the browser toggles the details open state natively — zero JavaScript for open/close mechanics. Screen readers announce it as a disclosure widget (semantic and correct). The menu itself is styled inside the details element, revealed on [open] selector. Works in every browser since 2020. This is the simplest, most-supported production pattern. Approach 2 — the modern Popover API (Demo 01): the primary action is a <button>; the dropdown trigger is a <button popovertarget="menu-01">. The menu is a <div id="menu-01" popover>. The browser handles show / hide / dismiss on Escape / dismiss on backdrop click natively. Anchor Positioning API (anchor-name + position-anchor + anchor()) positions the menu relative to the trigger with collision-aware behaviour, eliminating the JS floating-ui library entirely. Baseline support in Chrome 114+, Safari 17+, Firefox 125+. For older browsers, a 15-line polyfill or a @supports fallback to Approach 1 keeps it working. Both approaches ship real accessibility: aria-haspopup="menu" on the trigger, aria-expanded flipping true / false, focus management moves into the menu on open and back to the trigger on close, arrow keys navigate menu items, Enter / Space activate. This collection's Demo 01 and Demo 06 ship both patterns so teams can pick based on browser support requirements — Popover + Anchor for cutting-edge products, native <details> for maximum compatibility. What NOT to do: never use a plain <div onclick> with a JS-toggled class. That fails keyboard access, fails screen reader announcement, and requires an outside-click handler that competes with every other event listener on the page. The native primitives handle it all correctly.

Three production techniques ship in this collection. Technique 1 — proportional-width thumb with radio inputs (Demo 05, the iOS-style segmented control): each option is a hidden radio input plus a label. The thumb is a positioned pseudo-element sized to calc(100% / N) where N is the number of options. When a radio is :checked, a general-sibling selector on the parent sets the thumb's translateX to move it to the correct position (0, 100%, 200%, 300%, ...). Transition on transform only — compositor-friendly, GPU-accelerated, no layout thrash. This is the pattern iOS 26 ships in UISegmentedControl, and it's what Stripe, Linear, and every modern SaaS product uses for their segmented pickers. Zero JavaScript. Technique 2 — motion-path comet thumb (Demo 02, the offset-path arc travel): the thumb rides a curved offset-path: path('M ...') as it moves between options, tracing a subtle arc rather than a straight line. The path is a Bézier curve; offset-distance tweens from 0% to 100% based on which radio is checked. This is a modern polish move that reads as premium (the eye tracks curved motion as more organic than linear). Technique 3 — View Transitions with morphing thumb (Demo 03, shared-element FLIP): uses the CSS View Transitions API (view-transition-name) so the thumb is treated as the same DOM element across states. When the selection changes, the browser natively animates the thumb from its old position to its new one — no manual FLIP math, no requestAnimationFrame loop, no imperative animation code. Baseline support arrived in 2024 (Chrome 111+, Safari 18+). For older browsers, degrades gracefully to Technique 1's transform-tween pattern. Common pitfall: never animate left or margin-left or width to move the thumb — those trigger the layout + paint pipeline on every frame and tank Interaction to Next Paint on real mobile hardware. Always animate transform: translateX() so the animation runs on the compositor. Every demo in this collection is INP-safe.

Every button group in this collection ships the accessibility contract that Section 508, EN 301 549, AODA, DDA, and the European Accessibility Act require. Semantic HTML first — every interactive element is a real <button>, <input type="radio">, <input type="checkbox">, or <summary>. Never a <div onclick>. Real elements come with real keyboard support, real screen reader announcements, real focus management, real form participation — none of which you have to write yourself. ARIA where semantic HTML falls short — aria-pressed on toggle buttons (multi-select toolbar buttons), aria-current="page" or aria-current="true" on active items in single-select navigation groups, aria-expanded on split-button and dropdown triggers, aria-haspopup="menu" on split-button dropdowns, aria-label on every icon-only button so screen readers announce the action, role="group" with aria-label on the button group container. Keyboard navigation matches the widget type — radio groups use arrow keys to move between options (roving tabindex handled natively by the radio input semantics), toolbars use arrow keys with Home / End to jump to first / last, split buttons open menus on Enter / Space / Down Arrow. Tab enters the widget, tabs out to the next widget — it doesn't tab through every button inside a group (that would create tab-traps on toolbar-heavy screens). Focus indication survives every design — a :focus-visible ring is applied to every interactive element, using a high-contrast double outline (dark + light) so it reads against any button background. Rings never disappear inside a filled active state. In @media (forced-colors: active), rings switch to outline: 2px solid Highlight so Windows High Contrast mode shows the focus indicator using system palette. Touch targets — every button meets WCAG 2.5.5 44×44px minimum. Icon buttons that look smaller ship padding that expands the hit area to the required size. Motion respects prefers-reduced-motion — every animation is guarded. Transparency respects prefers-reduced-transparency where glass effects are used. Color contrast — every active state clears WCAG 1.4.3 AA (4.5:1 for normal text, 3:1 for large-text and non-text UI). The compliance floor is the same one healthcare / government / regulated fintech / insurance / legal products need. Ship these to a Section 508 audit and pass.

Multi-select button groups let the user pick multiple options simultaneously — unlike segmented controls or radio groups, where selection is mutually exclusive. Two production patterns ship. Pattern 1 — hidden checkboxes with visible label styling (Demo 14, the acid-glow multi-select chips): each chip is a <label> wrapping a hidden <input type="checkbox"> plus a visible span. When the checkbox is :checked, a general-sibling selector styles the label with a glow ring, brighter fill, and a checkmark. Multiple chips can be checked simultaneously. Form submission works natively (browsers include every checked checkbox in the form data). Zero JavaScript required. Screen readers announce each chip as “checkbox, checked / unchecked”. This is the pattern OpenSea uses for NFT trait filters, Amazon uses for product category filters, and Shopify uses for merchant-facing product tag pickers. Pattern 2 — <button aria-pressed> for stateful toolbar buttons (Demo 07, the icon toolbar): each toolbar button is a real <button type="button"> with aria-pressed="true" or aria-pressed="false". The pressed state is styled via [aria-pressed="true"] selector. Screen readers announce “toggle button, pressed / not pressed”. This is the pattern Google Docs, Notion, Linear, and every text-editor toolbar uses for the Bold / Italic / Underline pattern. Requires a small amount of JS to flip the aria-pressed attribute on click (or a :has()-based state machine for pure CSS). Both patterns support keyboard navigation, focus management, and screen reader announcements out of the box. Common failure mode: never use a <div class="active"> pattern for multi-select. That loses the semantic role, breaks form submission, and requires you to write the accessibility layer yourself. The native primitives handle everything correctly. Style at your leisure; leave the semantics alone.

Two specific high-value patterns in this collection. Web3 wallet-connect button grid (Demo 10): the pattern every crypto product ships to let users pick their preferred wallet before signing in. MetaMask, WalletConnect, Coinbase Wallet, Rainbow, Phantom (Solana), Trust Wallet, Ledger Live, and every hardware wallet integration all follow this pattern. The demo ships as a responsive auto-fit grid — grid-template-columns: repeat(auto-fit, minmax(160px, 1fr)) — so it reflows from a 5-across grid on desktop to a 2-across grid on mobile without duplicate breakpoint markup. Each provider tile is a <button> with the wallet logo (inline SVG for performance), the provider name, and a chevron or status indicator. Hover / focus states reveal a subtle glow. The active state carries aria-pressed="true". Real Web3 products then wire the click handler to window.ethereum.request({ method: 'eth_requestAccounts' }) or the equivalent WalletConnect / Coinbase SDK call. The demo ships the UI layer; the SDK integration is one line of JavaScript in your app. AI model selector (Demo 11): the pattern every LLM playground and AI product ships to let users switch between GPT-4, Claude 4.5 Sonnet, Gemini 2.0 Pro, Mistral Large, Llama 3.3, o1, etc. OpenAI Playground, Anthropic Console, Perplexity, Cursor's model picker, GitHub Copilot's model dropdown, and every AI product's model-selection UI ship variants of this. The demo ships as a segmented button group with provider badges (small pill next to the model name showing the provider), context-window indicator (128K, 200K, 1M), pricing tier badge (Free / Pro / Team). Hidden radios drive single-select state; the visible label styling is pure CSS. Real AI products then wire the click handler to their API's model parameter. Both demos are copy-paste-ready UI layers — you ship them with your Web3 SDK or LLM API integration. The accessibility floor is the same as every other button group in the collection: real interactive elements, ARIA announcements, keyboard navigation, focus indication, 44px touch targets, prefers-reduced-motion guards. This collection is the first free CSS button-group library to specifically address the Web3 wallet-connect and AI model selector verticals — both are $50-150 CPM ad tiers, so the traffic these patterns attract is disproportionately valuable.

Yes on both. Every demo is MIT licensed — free for personal and commercial projects, no attribution required (though a link back to codefronts.com is always appreciated). Every demo is plain HTML + CSS + optional vanilla JS with no build step, no framework wrapper, no dependencies. Drop the HTML into a React component's JSX (with className instead of class), a Vue single-file component's template, a Svelte component, an Astro island, or a SvelteKit page — the CSS ships as a scoped module, an inline <style> block, or a Tailwind arbitrary-value paste. React — use className, wrap the state in useState if you need it, but the CSS-driven state machines (hidden radios, :has(), native <details>) work without React state. React StrictMode double-mount is safe. Server-side rendering works without hydration flash because the initial state is CSS-driven, not JS-driven. Vue 3 — use v-model to bind the selected value to the hidden radio inputs. Svelte / SvelteKit — bind:group works with the radio pattern out of the box. Astro islands — wrap as client:load or client:visible only if the demo actually needs client-side state (most don't; they render on the server and the CSS handles interaction). Angular, Blazor, HTMX, Turbo, Rails ERB, Django, Laravel Blade, WordPress themes, and static HTML all work — the code is framework-agnostic. Content-Security-Policy compatibility: every demo works under a strict CSP (script-src 'self' without 'unsafe-inline') because no demo uses inline onclick handlers; interactions come from CSS selectors on hidden form inputs. Tailwind users: the CSS translates cleanly. display:grid + grid-template-columns:repeat(auto-fit,minmax(160px,1fr)) maps to grid grid-cols-[repeat(auto-fit,minmax(160px,1fr))]. border-radius:999px maps to rounded-full. backdrop-filter:blur() maps to backdrop-blur. @property registrations and named @keyframes belong in tailwind.config.js under extend.keyframes + extend.animation, or a small @layer utilities block. Every demo has been mentally tested at 320px / 600px / 1200px viewport widths per this site's responsive-first contract — the code you copy is the code that ships to your users at every width.