RenderFlex Overflow: Every Real Cause, Not Just "Wrap It in Expanded"

The yellow-and-black diagonal stripes are Flutter being honest with you. They're not a bug in the layout engine. They're Flutter reporting, accurately, that a Row or Column was asked to fit more content than the space available to it, and it's not going to silently clip or squash your UI to make that go away.

The advice you'll find everywhere is "wrap it in Expanded," and that's true often enough that it's become the reflex fix. It's also wrong often enough that reaching for it without understanding why causes a second, quieter bug: widgets that stretch to fill space they shouldn't.

Expanded forces a fill. Flexible allows a shrink. They are not interchangeable.

Expanded tells its child to take up all the remaining space in the Row or Column, whether it needs it or not. That's exactly right for something like body text that should wrap onto multiple lines instead of overflowing:

Row(
  children: [
    Expanded(
      child: Text('This text will wrap onto a new line instead of overflowing the row'),
    ),
    const Icon(Icons.star),
  ],
)

Flexible is the version to reach for when the child should be allowed to shrink but shouldn't be force-stretched to fill space it doesn't need:

Flexible(
  child: Text('Long title', overflow: TextOverflow.ellipsis),
)

Use Expanded on the wrong child and you'll trade an overflow warning for a layout where a button or icon stretches awkwardly across half the screen. That's a real, common outcome of applying the "wrap it in Expanded" advice without checking which behavior you actually want.

When the content is meant to be fully visible, scroll instead of squeezing it

Sometimes the actual problem isn't that a widget needs to shrink or share space, it's that the content is genuinely larger than the available area and squeezing it in any form would make it unreadable. That's a scrolling problem, not a flex problem:

SingleChildScrollView(
  scrollDirection: Axis.horizontal,
  child: Row(
    children: [ /* content that's meant to be fully visible, just scrollable */ ],
  ),
)

Wrap solves a different problem than Row entirely

If you're overflowing because you have a variable number of items of variable width (tags, chips, filter buttons), the fix usually isn't Expanded or scrolling at all. It's swapping the container itself. Wrap moves overflowing children onto a new line automatically:

Wrap(
  spacing: 8,
  runSpacing: 8,
  children: [
    // chips, tags, filter buttons, however many fit per row
  ],
)

Trying to force a variable-length list of chips into a Row with Expanded children usually just produces a different, uglier layout bug. If the content is naturally "flow to the next line," reach for Wrap before reaching for flex widgets at all.

The mistake that survives code review: testing one screen size

A layout that looks correct on your development device can overflow the moment it's opened on a smaller phone, in split-screen mode, or with a larger system font size from accessibility settings. This is the single most common way a "fixed" overflow bug reappears in production: the fix was verified against one viewport and never checked against a smaller one.

Before calling an overflow fix done, actually resize the window or test against a couple of real device widths, not just the one you developed on. It costs a few minutes and catches the exact failure mode that support tickets for "the app looks broken on my phone" usually turn out to be.

For the short version of the fix without the full walkthrough, see the RenderFlex overflow troubleshooting entry.