A table can fit inside a phone screen and still be hard to read. Five equal-width columns may squeeze words into vertical strips; switching off fixed widths may instead create a table that needs horizontal scrolling. Both behaviors can be legitimate outcomes of the WordPress Table block. The right fix depends on whether the reader must compare values across columns and whether the scrollable area remains usable.
This guide compares three choices using the same five-column table. It gives you a quick way to diagnose the failure, a scoped CSS option when the editor toggle is insufficient, and a rollback path. The measurements below come from an isolated local WordPress site running GeneratePress and LiteSpeed Cache. They are not a claim that every theme, cache configuration, phone, or assistive technology behaves identically.
Gutenberg tables on mobile: squeezed cells or hidden overflow?
Before adding CSS, look at the published page as a visitor at a narrow width. If the table fits but words wrap every few letters, inspect the Table block’s Fixed width table cells setting. WordPress documents that new Table blocks default to this setting and that you can turn it off in the block sidebar. The block’s frontend styles already include overflow-x: auto on its figure wrapper, but a fixed table that remains exactly as wide as that wrapper may have nothing to scroll. This is why adding another overflow-x: auto rule alone may change nothing. WordPress Table block documentation and the Gutenberg table stylesheet explain the underlying controls and styles.
This is a reported problem, not an invented edge case: a WordPress.org user described an overly slim mobile table, and an open Gutenberg issue discusses the readability trade-off. Those reports are community evidence; the comparison below is DocsHook’s separate, narrower browser test.
What DocsHook’s 375 px Gutenberg table test found
On 1 November 2026, we published a local-only test post on WordPress 7.1.4 with GeneratePress 3.6.1 and LiteSpeed Cache 7.9.2. It contained the same five-column, two-row Gutenberg Table block three times, with only the layout treatment changed. We viewed the anonymous frontend in Chromium 156 at 375 CSS pixels wide; the table wrapper was 300 pixels wide. LiteSpeed returned a cache miss and then a hit for the test page. We kept the words, header markup and cell padding the same. These measurements describe this local setup, not universal breakpoints or accessibility outcomes.
- Default fixed cells: the table stayed 300px wide. Its five headers were 60px each; the first body row became 351px tall. There was no table-level horizontal overflow to scroll.
- Fixed cells off: the table grew to 560px inside the same 300px wrapper. Horizontal scrolling appeared, and the first body row measured 147px tall. The browser chose uneven column widths based on content.
- Scoped scroll style: keeping the fixed-layout class but overriding it for this one table produced a 1334px table inside the 300px wrapper. The first body row was 45px tall. This preserved more horizontal reading space but required substantially more sideways travel.
The comparison shows a trade-off, not a single winning score. For this sample, switching off fixed cells gave the best first step: it reduced severe wrapping without imposing the very wide CSS version. At 768px and 1280px viewports, all three tables fit within their wrappers in this test. A table with shorter labels or fewer columns may work with the default. A dense comparison with long values may need a deliberately scrollable layout, shorter copy, or a different presentation altogether.
The sanitized test record lists the environment, measured widths, cache observations, rollback and limits. It contains no production data or test credentials.
Fix 1: shorten Gutenberg table content before changing layout
If the table contains only a few short columns, keep the default block and shorten headings or move explanatory text below it. Do not remove information needed to interpret a value merely to make a screenshot look tidy. Check whether a comparison really needs every column on a phone; if not, split unrelated facts into separate tables or use a list. In our five-column test, leaving the fixed layout unchanged gave visibly narrow cells, so this route would require changing the content, which we did not measure.
Fix 2: disable Gutenberg’s fixed-width table cells
Select the Table block, open its settings sidebar and turn off Fixed width table cells. Save the draft, then check the actual frontend at a phone width. In the isolated WordPress test this block setting created a 560px table and local horizontal overflow without custom CSS. It is reversible: turn the toggle back on. The result still depends on your words and theme; long strings may force a very wide column, and a visible scrollbar is not guaranteed on every device. A short “Swipe to view all columns” hint near the table can help, but the content must also remain understandable when scrolling.
Fix 3: add horizontal scrolling only to the affected table
When the toggle still compresses important data, add the class docshook-scroll-table in that Table block’s Advanced → Additional CSS Class(es) field. Keep fixed width cells on for this version, and verify that the published wrapper has wp-block-table docshook-scroll-table. Add the following CSS through your theme’s supported custom CSS area, first on a staging site or in a reversible draft workflow:
@media (max-width: 767px) {
.wp-block-table.docshook-scroll-table table.has-fixed-layout {
width: max-content;
min-width: 100%;
table-layout: auto;
}
.wp-block-table.docshook-scroll-table th,
.wp-block-table.docshook-scroll-table td {
min-width: 9rem;
}
}The selector is deliberately specific. Our first browser-fixture attempt targeted the table less specifically and failed to override Gutenberg’s .has-fixed-layout rule; the corrected selector also worked on the local WordPress frontend and produced the measured 1334px scrollable table. That width is a warning: a very wide table can make comparison tiresome even when it technically scrolls. Adjust the minimum width for the actual content, and use this only on the tables that need it. Remove the added class and CSS rule to roll back. If the class is missing from the frontend or your theme replaces the Table block markup, do not assume this snippet applies.
Keep Gutenberg table headers, captions and reading order accessible
Use the Table block’s header section and caption where they clarify the data. Header cells should be <th>, data cells <td>; more complex row-and-column relationships may need explicit header associations beyond the basic block output. The W3C WAI table tutorial explains the structural requirements. A scrollable container can look acceptable in a screenshot yet be awkward to discover or operate. W3C’s design-system table pattern shows one named, focusable wrapper approach; adding such a wrapper is a separate implementation step and was not part of our WordPress test.
We separately tested keyboard access in an isolated Chromium 156 fixture at a 375px viewport. From a preceding link, Tab moved to the overflowing non-fixed table, then to the scoped-scroll table. ArrowRight moved each focused scroll region 40px; ArrowLeft returned the scoped region to its starting position. This supports keyboard operation in that browser and fixture only. It does not establish touch behavior on a physical phone, screen-reader output, or keyboard behavior in other browsers. Those checks still belong in your final-page QA.
Avoid the blanket fix white-space: nowrap on every table cell. It can make natural-language cells unnecessarily wide. Also avoid turning each row into a visual “card” without checking that header-to-data relationships remain available to assistive technology. If readers need to compare values across columns, preserving the native table often matters more than eliminating every sideways swipe.
Verify the published Gutenberg table at phone width
- Keep a copy of the original table and CSS. Make one change at a time, and confirm the Table block remains valid in the editor.
- Check the saved page at narrow and wide widths, both logged in and as an anonymous visitor. If the frontend differs from the editor, compare the rendered HTML and any caching or optimization layer before changing more CSS. Our visitor-versus-editor cache diagnosis explains that separate branch.
- Confirm the page itself has no unwanted horizontal overflow; only the table wrapper should scroll. Try a short and a long value, the first and last columns, touch swiping, keyboard navigation and increased text size.
- Verify the caption and headers still describe the cells. If a CSS change fails or harms another table, remove its scoped class and rule, clear only relevant cache, and retest the anonymous page.
Our local WordPress test did not use DocsHook’s production theme settings or CDN, a physical phone or a screen reader. The separate keyboard check used one Chromium fixture rather than a cross-browser assistive-technology test. We therefore do not claim that this CSS is accessible or correct on every site. Recheck the final page with your own content, theme and devices before treating the snippet as a production fix.
Gutenberg table test environment and source limits
DocsHook browser measurement: isolated local WordPress 7.1.4 / GeneratePress 3.6.1 / LiteSpeed Cache 7.9.2, Chromium 156, 375px viewport / 300px table wrapper, 1 November 2026. A separate Chromium fixture supplied the narrow keyboard check; the sanitized record distinguishes the two. Product documentation: WordPress Table block controls and Gutenberg’s table CSS. Community reports: WordPress.org narrow-table report and Gutenberg issue #70454. Accessibility guidance: W3C WAI tables and W3C table pattern. Community reports establish the question; they are not proof that the same CSS is right for every site.