CSS Tricks for Long Tables: Sticky Header and Sticky Columns Together

1. Why long tables quickly become unreadable without sticky headers and columns

A table with hundreds of rows loses its header row from view as soon as the user scrolls further down, and with it the information about which column holds which value. In very wide tables with horizontal scrolling, the same thing happens to the first column, which usually carries the identifying value of a row, such as an order number or product name: without it, every number further to the right loses its context.

Both problems can be solved with position: sticky, without JavaScript, without a second, artificially synchronized copy of the header row, and without abandoning the semantic table structure. The real challenge is less about using sticky at all and more about combining both axes at once, picking the right scroll container, and handling the z-index conflicts that arise exactly where the pinned row and the pinned column overlap.

2. position: sticky for the header row: basics and requirements

position: sticky on a header row works by setting top: 0, letting the element scroll normally within its nearest scrolling ancestor until it reaches that position, and then keeping it pinned there. On HTML tables the property is typically set on thead th, though sticky on thead itself does not work reliably in some older browser engines, making setting the property on the individual th cells the more robust choice.

A working sticky setup also requires that no ancestor element sets overflow: hidden on an axis that would affect the sticky element, and that the scrolling container itself has a defined height with overflow-y: auto. If either requirement is missing, sticky visually behaves like static, with no obvious error in the console, which makes this particular mistake unusually hard to debug in practice.

.table-scroll {
  max-height: 480px;
  overflow-y: auto;
  overflow-x: auto;
}

thead th {
  position: sticky;
  top: 0;
  background-color: #0f172a;
  color: #fff;
  z-index: 2;
}

3. position: sticky for the first column: the same trick, a different axis

The same mechanism works on the horizontal axis for the first column, except here left: 0 replaces top: 0, and the relevant scroll container needs to be horizontally scrollable. Every cell in the first column, both th and td, gets position: sticky; left: 0;, which keeps it pinned at its left position while the rest of the row scrolls away horizontally underneath.

An important difference from the sticky header is that the first column absolutely needs an opaque background, because otherwise it floats transparently above the following columns and their content shows through as soon as the table scrolls horizontally. Without an explicit background-color on every sticky cell, the pinned column looks visually shifted or overlapped as soon as content scrolls by underneath it.

tbody td:first-child,
thead th:first-child {
  position: sticky;
  left: 0;
  background-color: #ffffff;
  z-index: 1;
}

thead th:first-child {
  background-color: #0f172a;
  color: #fff;
}

4. Combining a sticky header AND a sticky first column at once

Combining both techniques creates the top-left cell, the intersection of the pinned header and the pinned first column, where both sticky rules apply at once. That single cell therefore needs both top: 0 and left: 0, and it additionally needs a higher z-index than the other sticky elements, because it has to stay visible above both the rest of the header and the rest of the first column.

In practice, the cleanest way to define this corner is as its own, more specific selector rule, such as thead th:first-child, instead of relying on the combination of the two more general rules. That keeps it explicit that this one cell is a special case, and the order of the CSS rules in the stylesheet no longer matters for rendering correctly.

/* Sticky header row */
thead th {
  position: sticky;
  top: 0;
  z-index: 2;
  background-color: #0f172a;
  color: #fff;
}

/* Sticky first column */
tbody td:first-child,
thead th:first-child {
  position: sticky;
  left: 0;
  z-index: 1;
  background-color: #ffffff;
}

/* Top-left corner: sticky on BOTH axes, needs the highest z-index */
thead th:first-child {
  z-index: 3;
  background-color: #0f172a;
  color: #fff;
}

5. The z-index pitfall where the row and the column overlap

The classic pitfall happens when the three layers involved, the plain header row, the plain first column, and their shared corner, do not get clearly staged z-index values. Without that staging, scrolling sometimes shows the header overlapping the first column and sometimes the reverse, depending on which element appears later in the DOM and which stacking context the browser last updated, producing a visibly flickering or inconsistent result.

The reliable fix is a deliberate, documented ranking: the shared corner gets the highest value, the header row the second highest, the first column the lowest of the three sticky layers, and every other table content stays without an explicit z-index. That ranking should be written down as a comment in the stylesheet, because it otherwise tends to shift unintentionally with future changes.

/* z-index ranking for sticky table cells, from lowest to highest:
   1 = sticky first column
   2 = sticky header row
   3 = sticky top-left corner cell
   Do not change this order without checking all three overlaps. */
tbody td:first-child { z-index: 1; }
thead th { z-index: 2; }
thead th:first-child { z-index: 3; }

6. Understanding stacking contexts: why z-index sometimes just stops working

Sometimes a z-index that has been set correctly still does not behave as expected, and the cause is almost always a stacking context further up the tree. Any element that sets transform, filter, an opacity below 1, or even position together with a z-index value, opens a new stacking context, inside which all z-index values of descendant elements only apply relative to each other, not relative to the whole document.

For sticky tables that means concretely: if a wrapper element around the table accidentally carries one of these properties, for example because a card component uses transform by default for a hover effect, the internally correctly staged z-index values of the sticky cells can no longer reach above elements outside that wrapper. Debugging should therefore always start with the ancestors, not just the table itself.

7. Performance in very long tables: what sticky actually costs

position: sticky itself is cheap, because the browser calculates the positioning during layout and only has to update compositing during the actual scroll, without triggering a full reflow for every scroll frame. The real performance bottleneck in very long tables with thousands of rows is almost never the sticky mechanism itself, but the fact that the browser keeps every single row in the DOM and has to manage a separate compositing layer for every sticky cell.

For tables with several thousand rows, it therefore pays off less to optimize the sticky rules themselves and more to introduce virtualization, rendering only the rows currently within the visible area and replacing the rest with placeholder height. For most practical use cases with a few hundred rows, plain CSS sticky is entirely sufficient and virtualization is not needed at all.

8. The right scroll container: overflow, table-layout and width pitfalls

The scroll container carrying overflow: auto must be exactly the nearest scrolling ancestor of the sticky elements, because sticky always relates to that container, not the viewport, as soon as such an ancestor with a defined overflow exists. If the table is instead rendered directly in the normal page flow without its own scroll container, sticky automatically relates to the entire viewport, which is often undesirable on very long pages with plenty of other content.

It is also worth considering table-layout: fixed together with explicitly set column widths, because under table-layout: auto the browser only finalizes column widths after reading the entire table content, which can cause noticeable delays on very long tables and a visible recalculation of the sticky column's width while it loads.

.table-scroll {
  max-height: 480px;
  overflow: auto;
}

table {
  table-layout: fixed;
  border-collapse: separate;
  border-spacing: 0;
  width: 100%;
}

th:first-child,
td:first-child {
  width: 180px;
}

9. Checklist for robust sticky tables

A robust sticky table ultimately needs four connected building blocks: a clearly defined scroll container with overflow: auto and a fixed height, opaque background colors on every sticky cell, a documented z-index ranking for the three layers involved, and avoiding stacking-context-creating properties on ancestors that could accidentally break that internal ranking.

Once these four points are handled from the start, a long, wide table with a sticky header and a sticky first column can be built with CSS alone, without JavaScript libraries for virtualized scrolling or an artificially synchronized second header row. Only at several thousand rows does an additional virtualization strategy become relevant; for the vast majority of practical tables, the pure CSS approach is entirely sufficient.

10. Summary

11. FAQ: Sticky Headers and Columns in Long Tables: The Essentials at a Glance