Flutter Carousel Widget Component: M3 CarouselView, Hero and Multi-Browse Layouts (2026)

Across the ten industries we ship Flutter in, the carousel shows up wherever a product needs to surface multiple options without overwhelming the user. The use cases are everywhere once you start looking: onboarding swipes, product galleries, dashboard story tiles, news cards, promo banners. The choice between the new M3 CarouselView (built in since Flutter 3.16), the long-standing carousel_slider community package, a PageView with custom indicators, or a hand-rolled gesture-driven scroller looks small at design time and turns into a performance plus accessibility or M3-conformance question once the app hits real users. This guide walks through the flutter carousel widget component patterns we actually ship, the M3 layouts most tutorials still skip, and the production-grade fixes the community packages miss.

Two framing notes. Flutter 3.16 shipped CarouselView and CarouselView.weighted as first-class Material 3 components, which collapses the legacy carousel-package shootout into a much simpler decision: use the built-in for 80% of carousels, escape to packages only for fully custom transitions or non-Material design systems. Second: the community carousel_slider package is still maintained and worth keeping in a few use cases, but for new builds CarouselView is the M3-aligned choice. The migration off carousel_slider is usually under 60 lines of code per screen and saves measurable bundle weight on every platform.

When the flutter carousel widget component is the right primitive

CarouselView is the right primitive whenever you have a list of peer items where one is focal and the rest preview to either side, or where the user is expected to swipe through items in sequence one at a time. The two intents are different but the widget covers both cleanly through its named constructors. Use CarouselView when content needs swipe-through navigation between peer items: product galleries, onboarding screens, story tiles, news cards, promo banners. CarouselView ships the right M3 motion curve, the right snapping behavior, the right keyboard semantics, and the right layout math for multi-browse and hero layouts. The reason to escape to PageView or a custom scroll widget is rarely visual. It is usually because the design needs a non-Material motion curve or a transition the M3 spec does not cover. The other case where a custom scroll widget wins: when you need every item to size to its own content (variable widths across items) rather than the fixed-extent contract CarouselView enforces. That is rare in real designs, but it happens on some commerce screens where the marketing copy under each product is wildly different in length.

CarouselView basics: the M3 default

Most carousels in real apps are the uncontained variant where item width is fixed and peer items scroll past one at a time. The standard CarouselView takes a list of children and an itemExtent that controls how wide each item is. The widget handles snapping, scroll physics, and the M3 motion automatically. We use this constructor for most uncontained carousels: a product image gallery on a detail page, a feed of story tiles, a row of promo cards. The shrinkExtent prop is one most tutorials miss. It controls how narrow an item can get on partial scroll. Without it, items at the edge of the viewport snap to a tiny width that looks broken. Set shrinkExtent to about 30-40% of itemExtent for the cleanest motion. The other prop worth knowing is consumeMaxWeight (relevant on the weighted constructor): when false, the smallest item never gets compressed to zero, which prevents the visual of items disappearing entirely off the edge.

CarouselView(
  itemExtent: 280,                    // each card is 280dp wide
  shrinkExtent: 100,                  // minimum width on partial scroll
  itemSnapping: true,                 // snap to nearest item
  onTap: (index) => _openImage(product.images[index]),
  children: product.images.map((url) => Container(
    margin: const EdgeInsets.symmetric(horizontal: 4),
    decoration: BoxDecoration(
      borderRadius: BorderRadius.circular(16),
      image: DecorationImage(
        image: CachedNetworkImageProvider(url),
        fit: BoxFit.cover,
      ),
    ),
  )).toList(),
);

CarouselView.weighted: hero and multi-browse layouts

The weighted variant is where the Material 3 carousel really shows its design intent and where most of the visual character of the M3 spec lives. CarouselView.weighted lets each item own a relative weight that drives how much viewport space it takes. The flexWeights array controls the layout. [3, 2, 1] gives you the hero layout (one large item with two peeks). [1, 2, 5, 2, 1] gives you the multi-browse layout (one center-focal with two peeks on each side). The sizes update dynamically as the user scrolls, which is the M3 multi-browse motion the spec calls out specifically. The flexWeights values are relative ratios, not pixel sizes. The framework computes the actual width per item from the available viewport divided by the sum of weights. So [3, 2, 1] over a 360dp viewport means item 0 gets 180dp, item 1 gets 120dp, item 2 gets 60dp. As the user scrolls, the widget shifts weights from one slot to the next, creating the cascading-resize motion the M3 spec describes. The same flexWeights array also adapts naturally to a tablet at 800dp viewport without media-query branching. We have shipped the same CarouselView.weighted call site to phone and tablet builds and seen both work cleanly with zero per-device tweaks. That responsive-by-default behavior is one of the reasons we have stopped reaching for community carousel packages on new projects this year. The built-in does the responsive math correctly, where most community packages either ignore it or punt to a viewportFraction hack.

// Hero layout: 1 big + 2 small peeks
CarouselView.weighted(
  flexWeights: const <int>[3, 2, 1],
  consumeMaxWeight: false,
  itemSnapping: true,
  onTap: (i) => context.push('/article/${articles[i].id}'),
  children: articles.take(8).map((a) => _NewsCard(a)).toList(),
);

// Multi-browse layout: 5 items visible at once, center is focal
CarouselView.weighted(
  flexWeights: const <int>[1, 2, 5, 2, 1],
  consumeMaxWeight: false,
  itemSnapping: true,
  children: stories.map((s) => _StoryTile(s)).toList(),
);

Picking the right carousel layout: a decision matrix

Migrating from carousel_slider to CarouselView

The carousel_slider package shipped before CarouselView was a built-in. Most existing Flutter codebases use it. The migration is straightforward: the API surface is similar enough that swapping in CarouselView usually takes under 60 lines per screen. The catch: carousel_slider has built-in auto-play and a built-in indicator dot row; CarouselView ships neither. For auto-play, wire up a Timer.periodic; for indicators, draw them yourself with a Row of AnimatedContainer dots. Both are about 20 lines of code each. Three notes from our recent migrations. First, the API for viewport sizing differs (carousel_slider used viewportFraction; CarouselView uses itemExtent in dp) so you may want to compute the extent from MediaQuery.size.width in the build method. Second, the snapping curve is slightly different visually between the two. CarouselView uses the M3 emphasized motion curve, which feels weightier. Third, the page-changed callback API is different — carousel_slider exposed onPageChanged at top level, CarouselView wants you to listen to controller.position via a ScrollController.

Performance: where carousels make Flutter apps jank

Accessibility: what CarouselView gives you and what it doesn't

The five flutter carousel widget component bugs we catch in code review every month

The carousel widget pairs naturally with Card, since most carousel items end up wrapped in a Card.elevated or Card.filled with an image at the top and a title or price below. For the Card primitive that carousel items most often wrap on production builds, see ourguide to the flutter card widget. For how carousels fit into a production Flutter app (state plus performance and CI/CD coverage) our Flutter mobile app development field guide covers the practices we apply on every build.

Common questions about the flutter carousel widget component for production builds