How to Fix CSS Flexbox Text Overflow
Our guides are based on hands-on testing and verified sources. Each article is reviewed for accuracy and updated regularly to ensure current, reliable information.Read our editorial policy.
Long text overflowing a CSS Flexbox card is often caused by the flex item’s automatic minimum width. Setting min-width: 0 on the text container and overflow-wrap: anywhere on the text can resolve this problem without changing the card’s intended layout.
Consider a file card that looks perfectly fine with a short filename like “report.pdf.” Replace it with a long exported identifier, and the layout suddenly breaks. The badge stays in place, but the text extends beyond the card.
Before reducing the font size, increasing the card width, or hiding the overflow, inspect how the flex item calculates its minimum size.
This tutorial explains why Flexbox text overflows, how to reproduce and fix the problem, and how to build responsive cards that handle long filenames, URLs, and other unbroken strings.
Why Does Text Overflow in CSS Flexbox?
Flexbox distributes available space among items in a container. But a flexible item does not necessarily shrink to any width.
In a typical horizontal flex row with visible overflow, a flex item can have an automatic minimum width based on its content. A long, unbroken string may therefore prevent the item from becoming as narrow as the design requires.
Ordinary sentences contain spaces where browsers can break lines. Filenames, URLs, and long identifiers may have fewer suitable break opportunities.
MDN’s min-width documentation explains how automatic minimum sizing works for flex items. The exact behavior depends on the layout axis, overflow settings, and other sizing constraints.
When debugging a horizontal file card, separate two questions:
- Can the flex item shrink into the available space?
- Can its text wrap within that space?
The first is a sizing problem. The second is a text-wrapping problem. They require related but distinct CSS decisions.
Reproduce the Flexbox Text Overflow Bug
Start with the smallest example that demonstrates the problem. This makes it easier to identify the responsible CSS rule without interference from surrounding application styles.
Create a file named flex-card.html, paste the following code into it, and open the file in a browser.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, initial-scale=1">
<title>Flexbox Text Overflow Demo</title>
<style>
.card {
display: flex;
gap: 16px;
width: 320px;
padding: 16px;
border: 1px solid #829eaa;
font: 16px Arial, sans-serif;
}
.badge {
flex: 0 0 48px;
}
.copy {
flex: 1;
}
h2 {
margin: 0 0 10px;
font-size: 20px;
}
p {
margin: 0;
line-height: 1.5;
}
</style>
</head>
<body>
<article class="card">
<div class="badge">DOC</div>
<div class="copy">
<h2>Export ready</h2>
<p>QuarterlyResearchAndDevelopmentSummary2026Final</p>
</div>
</article>
</body>
</html>Output: The long filename extends beyond the card’s intended horizontal space, even though its text container uses flex: 1.
Replace the filename with report.pdf, and the card fits normally. This contrast helps isolate the long string as the trigger.
If you are debugging a larger application, isolate the relevant component and stylesheet first. A CSS formatter can make compressed or minified styles easier to inspect before creating a minimal reproduction.
Understand the Available Space in a Flex Row
The example has a fixed badge, a gap between flex items, and a flexible text area. Each contributes to the available space.
The card uses the default content-box sizing model, so its declared width of 320px excludes padding and borders.
| Layout Component | Width |
|---|---|
| Card content width | 320px |
| Fixed badge width | 48px |
| Gap between flex items | 16px |
| Available text width | 256px |
| Combined horizontal padding | 32px |
| Combined border width | 2px |
| Total outer card width | 354px |
The available space for the text item is:
320px - 48px - 16px = 256pxIn a Chromium test of this example, the unbroken filename occupied approximately 396px. That is 140px more than the text area provides.
The flex item’s automatic minimum size prevents it from shrinking sufficiently, causing the content to extend beyond the card.
Making the card wider might hide the problem for this particular filename, but an even longer string could cause the same failure.
How to Fix CSS Flexbox Text Overflow
The fix is to allow the flex item to shrink and give the long text permission to break.
Add these rules to the stylesheet in the original example:
.copy {
flex: 1;
min-width: 0;
}
.copy p {
overflow-wrap: anywhere;
}Output: The text container fits within the available space, and the filename wraps across multiple lines instead of extending beyond the card.
Step 1: Allow the Flex Item to Shrink
The min-width: 0 declaration changes the flex item’s minimum-width constraint.
In the original example, it allows the .copy element to shrink to the available 256px.
But shrinking the container does not automatically create line breaks. The long filename may still extend beyond its narrower boundary.
This explains why adding min-width: 0 alone sometimes appears to make no visible difference.
Step 2: Allow the Long Text to Wrap
The overflow-wrap: anywhere declaration allows the browser to introduce breaks within an otherwise unbreakable string when necessary.
It also affects min-content sizing, which is the minimum intrinsic size calculated using the available line-breaking opportunities.
As a result, overflow-wrap: anywhere may resolve the automatic minimum-size problem without a separate min-width: 0 declaration in some layouts, including this isolated example.
Keeping both declarations makes the text container’s ability to shrink explicit. It also provides a useful starting point when the component becomes more complex.
Browser Test Results: Which CSS Fix Actually Works?
The original file card was tested in Chromium 144.0.7559.96 using the exact filename, dimensions, and font declaration shown above.
Each CSS configuration was tested separately by comparing the card’s internal width, measured using clientWidth, with the horizontal extent of its content, measured using scrollWidth.
| CSS Configuration | Card clientWidth | Card scrollWidth | Result |
|---|---|---|---|
| Original CSS | 352px | 476px | Overflow |
min-width: 0 only |
352px | 476px | Text still overflows |
overflow-wrap: break-word only |
352px | 476px | Overflow |
overflow-wrap: anywhere only |
352px | 352px | Text wraps |
min-width: 0 and overflow-wrap: anywhere |
352px | 352px | Text wraps |
Single-line ellipsis with min-width: 0 |
352px | 352px | Text is truncated |
Test conditions: The original card retained its 320px content width, 16px padding, 1px border, fixed badge, and Arial font declaration. Measurements describe this specific Chromium environment and may differ with other fonts, browsers, or surrounding styles.
The card’s clientWidth is 352px because it includes horizontal padding but excludes the border.
The results demonstrate two important points. First, allowing the flex item to shrink does not necessarily prevent its contents from overflowing. Second, a card can report no horizontal overflow even when some text is intentionally hidden by an ellipsis.
Overflow-wrap: Anywhere vs. Break-word
Both overflow-wrap: anywhere and overflow-wrap: break-word allow long strings to wrap. Their important difference is how those additional break opportunities affect intrinsic sizing.
| Property Value | Breaks Long Strings? | Effect on Min-content Sizing |
|---|---|---|
normal |
Only at normal break opportunities | No additional break opportunities |
break-word |
Yes, when necessary | Introduced breaks are not considered |
anywhere |
Yes, when necessary | Introduced breaks are considered |
MDN’s overflow-wrap reference documents this distinction.
In the tested file card, break-word alone does not resolve the problem because the text item’s automatic minimum size remains too large.
With min-width: 0 added to the flex item, break-word can also wrap the text within the narrower container.
The anywhere value is particularly useful for long filenames, URLs, and identifiers because it also introduces break opportunities into min-content sizing.
Choose Text Wrapping or Truncation Based on the Content
Fixing horizontal overflow does not always mean wrapping text onto multiple lines. The right choice depends on what users need to see.
A filename might contain an important version number or extension near its end. Hiding those characters can make similar files difficult to distinguish. A compact navigation label, in comparison, may be suitable for truncation.
| Approach | Suitable Use | Trade-off |
|---|---|---|
overflow-wrap: anywhere |
Filenames, identifiers, URLs, and descriptions | Content may span multiple lines |
| Single-line ellipsis | Compact labels and constrained list views | Part of the visible text is hidden |
overflow: hidden alone |
Intentionally clipped content | May conceal meaningful text without indicating truncation |
Use Ellipsis for Single-Line Text
For a deliberate single-line layout, retain min-width: 0 on the flex item and use a dedicated class on the text element.
For example, apply the following rules to a paragraph with the class filename:
.copy {
flex: 1;
min-width: 0;
}
.filename {
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}Output: The filename remains on a single line. An ellipsis indicates that some characters are hidden.
Each declaration serves a purpose:
white-space: nowrapkeeps the text on one line.overflow: hiddenclips text extending beyond the element’s boundary.text-overflow: ellipsisindicates that the text has been truncated.
The element must have a constrained width for the ellipsis to appear.
Provide Access to the Full Filename
If you truncate important information, give users a dependable way to inspect the complete value.
A file details panel, expandable disclosure, or copy-filename control can provide that access. A tooltip that appears only on hover is not sufficient for touch users and may be unsuitable for keyboard users.
A native HTML details element provides a straightforward solution. Its summary element acts as the disclosure control without requiring custom JavaScript.
Use separate CSS classes for the truncated filename and the expanded filename. Otherwise, a broad selector such as .copy p may accidentally apply the ellipsis rules to both elements.
Build a Responsive Flexbox Card That Handles Long Text
There is another issue with the original example. The card’s 320px width excludes its padding and borders, giving it an actual outer width of 354px.
At a 320px viewport, the card can still cause horizontal page scrolling even after its internal text overflow has been fixed.
A responsive version should use a width that fits its parent and include padding and borders in that width.
Complete Runnable Example
The following example combines responsive sizing, explicit minimum-width control, single-line truncation, and a disclosure that reveals the full filename.
It also uses a container query so the card can switch to a vertical layout when its available container becomes narrow.
Save the code as responsive-flex-card.html and open it in a browser.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, initial-scale=1">
<title>Responsive Flexbox File Card</title>
<style>
body {
margin: 16px;
font: 16px Arial, sans-serif;
}
.card-slot {
width: 100%;
max-width: 320px;
min-width: 0;
container-type: inline-size;
}
.card {
display: flex;
align-items: flex-start;
gap: 16px;
width: 100%;
box-sizing: border-box;
padding: 16px;
border: 1px solid #829eaa;
border-radius: 8px;
}
.badge {
flex: 0 0 48px;
padding: 8px 0;
text-align: center;
background: #e5edf2;
border-radius: 4px;
max-width: 100%;
overflow-wrap: anywhere;
}
.copy {
flex: 1;
min-width: 0;
}
.copy h2 {
margin: 0 0 10px;
font-size: 20px;
overflow-wrap: anywhere;
}
.copy p {
margin: 0;
line-height: 1.5;
}
.filename {
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.wrap,
.full-filename,
summary {
overflow-wrap: anywhere;
}
details {
margin-top: 8px;
}
@container (max-width: 260px) {
.card {
flex-direction: column;
}
.badge {
flex: 0 0 auto;
padding: 8px;
box-sizing: border-box;
}
.copy {
flex: 0 1 auto;
width: 100%;
}
}
</style>
</head>
<body>
<div class="card-slot">
<article class="card">
<div class="badge">DOC</div>
<div class="copy">
<h2>Export ready</h2>
<p class="filename">
QuarterlyResearchAndDevelopmentSummary2026Final
</p>
<details>
<summary>Show full filename</summary>
<p class="full-filename">
QuarterlyResearchAndDevelopmentSummary2026Final
</p>
</details>
</div>
</article>
</div>
</body>
</html>Output: The card displays the filename on a single line with an ellipsis. Selecting “Show full filename” reveals the complete string, which wraps across multiple lines. When the surrounding container becomes narrow, the card switches to a vertical layout.
Notice that the expanded paragraph uses .full-filename, not .filename. This prevents the ellipsis rules from affecting the disclosed text.
If you prefer wrapping instead of truncation, replace the first paragraph’s class with wrap and remove the disclosure element. The existing stylesheet will allow the entire filename to wrap directly inside the card.
Why Container Queries Help Responsive Components
A standard media query checks conditions such as the browser viewport’s width.
That works for many page layouts, but it does not always help a reusable component. A card may sit inside a 200px-wide dashboard sidebar even when the browser window is much wider.
In the example, container-type: inline-size establishes the surrounding .card-slot as a query container.
The @container rule then adjusts the card when that container is 260px wide or narrower, rather than relying on the entire browser viewport.
MDN’s CSS container queries guide explains how this approach works.
The appropriate breakpoint depends on the component’s content and design. If you need to support browsers without container-query support, provide a suitable fallback layout.
Responsive Browser Test Results
The updated card was tested in the same Chromium environment at different viewport and container widths, with the full filename disclosure open.
| Viewport Width | Card Container Width | Layout | Document Scroll Width |
|---|---|---|---|
| 320px | 288px | Horizontal | 320px |
| 260px | 228px | Vertical | 260px |
| 160px | 128px | Vertical | 160px |
| 800px | 100px | Vertical | 800px |
In each test, the document’s scroll width matched its viewport width, so no horizontal page overflow occurred. The expanded filename also wrapped within its available text area.
The 100px container test is particularly useful because it demonstrates that the component responds to its parent even when the viewport remains wide.
What If Text Still Overflows After the Fix?
Sometimes the minimum-width constraint belongs to an ancestor rather than the immediate text container.
For example, a card may sit inside a dashboard content column that is itself a flex item. If that outer item refuses to shrink, changing only the filename’s container may not resolve the overall layout problem.
Consider this simplified component structure:
<div class="layout">
<aside class="sidebar">Navigation</aside>
<main class="content">
<!-- File card component goes here -->
</main>
</div>Keep the existing card and badge styles from the previous example, then add the following outer layout rules:
.layout {
display: flex;
gap: 16px;
}
.sidebar {
flex: 0 0 160px;
}
.content {
flex: 1;
min-width: 0;
}
@media (max-width: 480px) {
.layout {
flex-direction: column;
}
.sidebar {
flex: 0 0 auto;
}
.content {
width: 100%;
}
}The .content element can now shrink within the outer layout, while the existing card rules handle the long filename. The media query also prevents the fixed sidebar from consuming too much space on narrow screens.
When debugging nested layouts, inspect the rendered DOM in browser developer tools. Malformed markup may create a structure that differs from what your CSS selectors expect. An HTML validator can help identify basic markup errors, although it does not diagnose Flexbox sizing behavior.
For internationalized layouts, the logical property min-inline-size: 0 can be useful when the relevant constraint lies along the inline axis rather than a fixed physical direction.
Avoid applying a universal minimum-width reset without understanding which element caused the original problem.
How to Verify Flexbox Text Overflow in Browser DevTools
A layout that looks fixed at one screen size may still fail with another filename, font, or surrounding component.
Instead of relying only on visual inspection, measure the affected elements.
Measure the Card and Filename Separately
Open either HTML example in your browser, open the developer tools console, and run:
const card = document.querySelector(".card");
const filename = card.querySelector(".copy p");
console.table([
{
element: "Card",
clientWidth: card.clientWidth,
scrollWidth: card.scrollWidth,
overflows: card.scrollWidth > card.clientWidth
},
{
element: "Filename",
clientWidth: filename.clientWidth,
scrollWidth: filename.scrollWidth,
overflows: filename.scrollWidth > filename.clientWidth
}
]);Output: The console displays the visible internal width and horizontal content extent of both the card and the filename paragraph.
For the original 320px-content-width card using single-line ellipsis, the Chromium measurements were:
| Element | clientWidth | scrollWidth |
|---|---|---|
| Outer card | 352px | 352px |
| Filename paragraph | 256px | 396px |
The outer card reports no horizontal overflow. But its filename is still wider than the visible text area because it is intentionally truncated.
This explains why inspecting only the outer container can miss hidden content.
These measurements are useful diagnostic signals, not a complete readability or accessibility test.
Test Realistic Content and Display Conditions
Before adopting the fix in production, test more than the sample filename.
| Test Condition | What to Inspect |
|---|---|
| Short filename | Baseline alignment and spacing |
| Long unbroken identifier | Wrapping and horizontal overflow |
| Narrow viewport or parent container | Card dimensions and page scrolling |
| Larger text and browser zoom | Content height and neighboring controls |
| Translated text and different writing systems | Line breaking, glyphs, and reading direction |
| Keyboard and touch interaction | Access to the complete filename |
| Production and fallback fonts | Text widths and wrapping behavior |
The examples and measurements in this guide were tested in Chromium. Safari and Firefox were not included in the measured tests. Check those browsers separately if they are part of your application’s supported browser matrix.
Test the Layout With Your Final Font
Different font families, weights, and glyph widths can change how much text fits on a line. A card that works with Arial may wrap differently when its production web font loads.
For products using custom typography, this is especially relevant. Font foundries such as TypeType offer custom typeface services, which can introduce font metrics that differ from the original system-font prototype.
Test both the production font and its fallback, including any layout changes that occur while the web font loads. Changing the font may alter the appearance of an overflow problem, but it is not a substitute for correcting the layout constraint.
Also check licensing before including commercial font files in a public reproduction. Permission to use a font on a website does not necessarily include permission to redistribute its binaries.
The examples in this tutorial use Arial with a sans-serif fallback, so no downloaded font files are required.
Final Thoughts
Debugging long text in CSS Flexbox cards becomes easier when you separate container sizing from text wrapping.
Start with a minimal reproduction, calculate the available space, and identify the element imposing the minimum-size constraint. Then decide whether the full text should wrap or be deliberately truncated.
For a typical long-filename card, min-width: 0 on the flex item and overflow-wrap: anywhere on the text provide a practical starting point.
Test the result with realistic content, narrow containers, final font assets, and supported browsers. Record why you chose the fix and whether the component preserves access to the complete text.
A reliable layout should handle the content users actually provide, not just the short sample strings used during its initial design.



Comments
Comments are provided by Disqus, which sets cookies and processes data under its own privacy policy.