How do you handle a data-heavy table on a small screen without losing the data?

A dense table survives a small screen through one of four deliberate patterns, each trading completeness against readability: keep it whole and let it scroll horizontally, restructure each row into a stacked card, prioritize down to the few columns that matter and tuck the rest away, or make rows progressively expandable so detail appears on demand. The right method follows which columns the user actually needs on the go. What you must not do is let the table scale down and scroll however it lands, shrinking text into illegibility, because that loses the data in practice even though it technically kept every cell.

Horizontal scroll is the most faithful option and the bluntest. You keep the full grid at a readable size and let the user swipe sideways through columns, which preserves every relationship and every value exactly as designed. It works well for genuinely tabular comparison data, a spec sheet, a financial statement, where the structure itself is the point and users expect to scan across. Its cost is that off-screen columns are invisible until scrolled to, so it favors completeness over at-a-glance readability, and it leans on a clear scroll affordance so people know more exists to the right.

Stacked cards trade the other way. Each row becomes its own block with the column headers repeated as inline labels, “Name: Acme, Status: Active, Renewal: March,” so nothing is hidden and everything is readable in a single column. The data is fully preserved and easy to read one record at a time, which suits lists where users care about individual entries more than cross-row comparison, a roster, an order history. The cost is that comparing across records gets harder, because the side-by-side alignment that made the table a table is gone, replaced by vertical scrolling through repeated labels.

Column prioritization and progressive expansion are the surgical options. Prioritizing shows only the two or three columns a mobile user needs first and moves the rest behind a tap or a detail view, betting that on the go people want the essentials, not the full record. Progressive expansion keeps a compact row that opens to reveal the remaining fields when tapped, so the overview stays scannable and the depth is one gesture away. Both lean toward readability over instant completeness, and both depend on correctly guessing which columns are the essentials, which is a content judgment, not a layout default.

The edge case is that no single pattern wins everywhere, and the wrong-fit pattern loses data as surely as shrinking does: stacked cards bury comparison, aggressive prioritization can hide a column someone needed, and horizontal scroll can leave critical numbers off the first screen. So the choice is a tradeoff to make on purpose, not a formula. Start by asking which columns the user truly needs on a phone and how they use the data, compare, look up one record, or skim, then pick the pattern that protects that use, and verify the full data stays reachable in every case. Choose the table pattern deliberately, and the small screen keeps the data instead of crushing it.