Mobile Friendly Tables: How to Design Them for Small Screens

A mobile friendly table is a data table that people can read and use comfortably on a phone. In this guide, we at Talha Aslan and team share the methods we use most in client projects. We cover horizontal scrolling, a sticky first column, card layouts and accessible headers. You will also see which method fits which kind of data, how to test it and what to check before launch.

In short, there is no single correct pattern. Comparison data wants to stay side by side. A list of records, on the other hand, reads better as cards. So before you pick a method, find out what readers actually look for in the table. The sections below walk you through that decision step by step.

Why do tables break on mobile screens?

A table that looks fine on a desktop usually fails on a phone in three ways. First, the columns exceed the viewport and the whole page scrolls sideways. Second, cells shrink until words wrap letter by letter. Finally, the header row leaves the screen, so readers forget what each number means.

• Overflow: The table forces the rest of the page to scroll horizontally.
• Squeezing: Every column gets an equal share, and long text becomes unreadable.
• Lost context: Once the headers and first column disappear, the cells lose their meaning.
• Tap problems: Links and buttons inside cells become too small for a finger.

The problem is not only visual, though. Templates that fake tables with div boxes remove the row and column relationships for screen readers. Therefore, fixing the mobile layout must never break the underlying structure.

Do you really need a table at all?

Not every table needs to be a table. A two column list of features and descriptions often reads better on a phone as a description list or as short paragraphs with headings. Likewise, a single row of pricing does not justify table markup.

A table earns its place when the data has a two way relationship. For example, when readers compare three plans across five features, they read both across rows and down columns. In that case, you adapt the table to the narrow screen instead of removing it. Put simply, ask one question: are readers comparing this data or just reading it?

You usually make this call during page planning, not after the design is done. With a mobile first design approach, you plan content for small screens first, so the need for a table becomes clear early. If your site has data heavy pages, we can plan this together as part of our web design service and prepare a quote that fits your project.

Which mobile friendly table pattern fits which data?

The structure of your data decides the pattern. The comparison below sums up the four approaches we meet most often in practice. Still, treat it as a starting point and always test it with your own data.

In practice, we often combine these patterns. For instance, horizontal scrolling and a sticky first column usually work well together. Cards, meanwhile, shine when there are many columns but each row stands on its own.

How do you set up horizontal scrolling correctly?

The core rule of horizontal scrolling is simple: the table scrolls, the page does not. To achieve this, you wrap the table in a container and allow horizontal overflow only on that container. As a result, headings, paragraphs and navigation keep their normal width.

The W3C Understanding Reflow page adds an important detail here. The criterion asks content to work at a width of 320 CSS pixels without two dimensional scrolling. However, it treats data tables as an exception, because tables need a two dimensional layout to make sense. Content around the table, such as headings, search fields and pagination, still has to reflow.

1. Put the table inside its own scroll container.
2. Give cells a sensible minimum width so words do not wrap letter by letter.
3. Signal that more content exists, for example with a cut off last column, a shadow or a short note.
4. Check that the rest of the page does not overflow at 320 pixels.

This way, the page itself stays still while readers work with the table. To keep the overall scroll rhythm smooth, see also our guide on designing the scroll experience.

Making the scrollable table region usable for everyone

Swiping with a finger is easy. For keyboard users, however, a scroll container often stays out of reach. If it holds no focusable link, people cannot tab into it and cannot scroll sideways. That is why you should make the container itself focusable.

In practice, you give the container a tabindex of zero, assign it a region role and add a short label. A label such as "Plan comparison, scrolls horizontally" works well. Screen readers then announce what the area is, and keyboard users can scroll with the arrow keys. Also remember to show a clear focus outline.

• Can the scroll container receive keyboard focus?
• Does a clear outline appear on focus?
• Is the topic of the table clear from the label?
• Does the scroll hint rely on text, not only on color?

These details look small. Still, they are among the points accessibility audits miss most often. For the wider framework, our guide to WCAG standards is a good place to start.

How does a sticky first column work?

A sticky first column keeps row names in place while readers scroll sideways. In a plan comparison, for example, the "Monthly report" row label stays pinned to the left. As readers scroll right, they match each plan value to that row. So the context never disappears.

You build this with sticky positioning in CSS. According to the MDN documentation on position, a sticky element offsets itself relative to its nearest scrolling ancestor. It also needs at least one threshold, such as a left inset of zero. Without a threshold, it behaves just like relative positioning. In addition, if another box with an overflow setting sits in between, the column may stick to the wrong box.

1. Give the first column cells sticky positioning and a left threshold.
2. Give the pinned cells an opaque background; otherwise scrolling text shows through.
3. Add a thin shadow or border on the right edge to make the split clear.
4. Limit the width of the first column; on narrow screens, aim for no more than a third of the viewport.

That said, do not add a sticky column to every table. If the first column holds long text, pinning it leaves no room for data. In that case, a shorter row label or a card layout works better.

When does a sticky header row help?

In long tables, readers forget the column headers as they scroll down. A sticky header row solves this. The headers stay at the top of the screen, so every row keeps its meaning. The difference is clear in order lists, stock tables or class schedules with dozens of rows.

However, one mistake comes up often. If your site already has a sticky top menu, the table header slides under it and vanishes. Therefore, set the top threshold of the table header to match the menu height. We cover the wider effects of sticky menus in our post on how a sticky header affects conversion.

Moreover, when both the header row and the first column are sticky, the top left cell must stay fixed in both directions. You give that cell a higher stacking order than the others. As a result, cells do not overlap during scrolling. For short tables, a sticky header adds little value. Below about ten rows, we usually skip it.

When should you turn a table into cards?

In a card layout, each row becomes its own box on narrow screens. Headers move next to each value as labels. For example, "Order no", "Date", "Total" and "Status" stack inside one card. Readers no longer scroll sideways; they only scroll down.

This pattern shines when rows are independent of each other. Order history, listings, event calendars and appointment lists are typical examples. Readers do not compare rows here. Instead, they look for a specific record and check its details. Consequently, a vertical card layout matches how people naturally read on a phone.

On the other hand, cards fail for comparison tables. When readers compare three plans across five features, cards force them to scroll back and forth. They have to hunt for the same feature in different cards. So the rule is simple: use scrolling and a sticky column for comparisons, and use cards for independent records.

• Are the rows independent? Cards fit.
• Do readers compare column by column? Horizontal scrolling fits.
• Is the row name the key to everything? Add a sticky first column.

Where do the labels in a card layout come from?

In a card layout, every value needs a label next to it. Otherwise, readers cannot tell whether "12.03" is a date or an amount. The most common approach adds each column header to its cells as a data attribute. For example, every cell in the "Date" column carries "Date" in a data-label attribute.

Then, on narrow screens, CSS reads this attribute and prints it before the cell value. That way, you do not need a separate mobile table, because the same HTML works in two layouts. Writing labels by hand, though, invites errors. For that reason, we recommend a template or CMS setup that copies headers into cells automatically.

There is one more point to watch. When you change the display value of table elements, some browser and screen reader pairs may drop the table semantics. Therefore, always test the card version with a screen reader. If you find problems, you can restore the structure by declaring row, cell and header roles explicitly.

How do you code accessible table headers?

The foundation of an accessible table is the right cell type. The W3C WAI tables tutorial states that header cells use th and data cells use td. When a screen reader reaches a cell, it also reads the related header. Readers then hear something meaningful, such as "Pro plan, monthly report, included".

When the direction of a header is unclear, the scope attribute steps in. You use col for column headers and row for row headers. For a group header that spans several columns, you need colgroup, and for one that spans several rows, rowgroup. The MDN page on table accessibility also explains id and headers pairing for multi level headers. Still, it notes that this needs much more markup and that scope is usually enough.

1. Wrap the first row in thead and make its cells th.
2. Make the first column with row names th as well, with a row scope.
3. Use group scope on header cells that span several columns or rows.
4. Never leave a header cell empty; even the corner cell needs a short name.

This structure also serves the WCAG criterion on info and relationships. In other words, relationships that you show visually also become readable by software.

Table captions and short reading notes

A caption is the visible title that describes the topic of a table, and it comes first inside the table element. MDN points out that screen reader users rely on the caption to decide whether to read the table at all. So a caption is a shortcut that saves people from listening to dozens of cells.

On mobile, captions bring one more benefit. A table often fills the whole phone screen, and readers can no longer see the heading above it. A short, clear caption right on top answers the question "what am I looking at?" instantly. For example, "Monthly service scope by plan" is enough.

For complex tables, you can also add a one sentence reading note below the caption. Something like "Scroll right to see all plans" helps a lot. However, avoid the old summary attribute. MDN reminds us that it is deprecated and invisible to sighted users. In short, write any explanation as visible text for everyone.

Column priority and show or hide controls

In some tables, not every column carries the same weight. In a product list, name, price and stock status are primary data. Weight, dimensions and barcode can stay secondary. With column priority, you show only the primary columns on narrow screens and leave the rest to the reader.

Hiding a column completely is risky, though. If readers do not know the data exists, they never look for it. That is why hidden columns always need a clear control. A "Show all columns" button or a column picker menu works well. Also announce the state of that control to screen readers.

• Choose the primary columns from user research or support requests.
• Never delete a hidden column; only change its visibility.
• Consider remembering the chosen columns after a page reload.
• Keep the data in the HTML for search engines and screen readers.

This way, you offer a clean screen and full access to the data at the same time. The approach works especially well in admin dashboards and long product catalogs.

How do you make numbers and cell content readable on mobile?

On a narrow screen, every character counts. So simplifying cell content can matter even more than the layout itself. For example, instead of writing "USD" in every cell, move the unit into the column header, as in "Total (USD)". Each cell then holds only the number.

• Align numbers to the right so digits line up for comparison.
• Align text to the left; avoid centering it.
• Turn on tabular figures so numbers do not jitter.
• Limit long text to two lines in a cell and move details behind a link.
• Show included and not included states with text, not only icons.

Color matters as well. A rule such as "a red cell means out of stock" loses information for readers who cannot tell colors apart. Therefore, also write the status as a word. When you set the difference between text and background, apply the principles from our guide on how to use contrast in design. Finally, thin row borders often look cleaner than zebra stripes on small screens.

Touch targets, zoom and interaction inside tables

If cells hold links, buttons or checkboxes, people must be able to tap them on mobile. When two links sit side by side in a tight cell, readers often hit the wrong one. So you give interactive elements enough padding and space them apart.

Blocking zoom is another common mistake. Some templates disable page zoom to protect the table layout. Yet zoom is the most basic tool for anyone who struggles with small text. Instead of disabling it, build the table so it survives zooming.

It also helps to place key actions where thumbs reach easily. For instance, a "Details" button at the end of a row may sit at the far right of a scrolled table. Readers may never notice it there. In that case, keep the button close to the first column. We explain comfortable thumb areas in our post on the thumb zone in mobile design.

Example scenario: a service plan comparison table

As an example scenario, imagine a service page with three plans. On desktop, the table has four columns: the feature name and three plans. On a phone, these four columns do not fit into 360 pixels, and readers cannot compare the plans.

Cards would be the wrong choice here, because the reader's main task is to compare. Instead, we apply the following setup:

1. We place the table in a focusable scroll container.
2. Next, we pin the first column with the feature names and limit its width.
3. We keep plan names in the header row short and trim long marketing names.
4. Included and not included values appear as an icon plus text.
5. We add a note above the table: "Scroll right to see all plans".

Readers now look at the first column to know what each row means, and they swipe between plans. Plan tabs are another option. However, tabs remove the ability to see two plans at once. For that reason, we prefer the scrolling table when the comparison itself matters.

Example scenario: order history and record lists

For a second example scenario, take an order history in a customer account. Each row shows an order number, date, item count, total, status and a "Details" link. Users usually want to find one specific order. They do not compare rows with each other.

That is why cards are the right choice here. On narrow screens, each order turns into a card. The order number and status sit at the top, because that is what users look for first. Date and total follow, and a full width "Details" link sits at the bottom.

• Show the status with both color and words, such as "Shipped" or "Completed".
• Leave clear space between cards so rows do not blur together.
• Add pagination or a "Load more" control for long lists.
• Keep filter and search fields above the cards at normal width.

On desktop, the same data stays a classic table. In other words, one HTML structure serves two layouts depending on screen width. This approach lowers maintenance effort and keeps the content consistent.

Why should table data stay in HTML instead of an image?

Some sites try to solve the mobile problem by adding a table as a screenshot. That feels practical in the short term. In the long term, however, it causes three losses. First, the image shrinks on a phone and becomes hard to read without zoom. Second, screen readers cannot reach the cells in the image. Third, search engines understand image data less well than text.

Moreover, updating an image table means producing a new file every time. If prices or scope change and the team forgets this step, old information stays on the page. So we always keep the data as an HTML table and solve the mobile layout with CSS. As a result, the content lives in one place and shows up equally accurate on every screen.

When are ready made table plugins good enough?

Many CMS plugins offer mobile table features. For a simple blog table, these plugins often do the job. Before you pick one, though, check a few points. Some plugins rebuild the table with div boxes and strip the accessible structure.

• Does the plugin output real table, th and td elements?
• Can you enter a caption and scope values?
• Does the scroll container receive keyboard focus?
• How much extra code does the plugin load on the page?

If any answer is "no", a small table component built for your theme is usually the healthier choice. For example, a few lines of CSS instead of a heavy plugin protect both speed and accessibility.

How do you test a mobile friendly table?

Testing a mobile friendly table takes more than opening the page on a phone. A systematic check covers different widths, the keyboard and a screen reader together. We follow the sequence below in our projects.

1. Set the browser developer tools to 320 pixels wide and check whether the page overflows.
2. Zoom the desktop page to 400 percent; the content should stay readable.
3. Reach the table with the keyboard only and try to scroll sideways.
4. Listen to a few cells with a screen reader and check that you hear the headers with each cell.
5. Try portrait and landscape orientation on a real phone.

For a quick first check, you can use our mobile friendly test tool. Still, do not let tool results replace manual testing. Large tables can also affect page speed. Especially with thousands of rows, pagination helps you protect your Core Web Vitals.

Mobile friendly table checklist before launch

Before you publish, tick off the list below one item at a time. This checklist covers the mistakes we see most often in practice, and it takes only a few minutes.

• Is a table really needed, or would a list work better?
• Does the rest of the page avoid horizontal overflow at 320 pixels?
• Is the table in its own scroll container, and does it take keyboard focus?
• Are header cells th, with correct scope values?
• Does the table have a visible caption?
• If needed, are the first column or header row sticky, with an opaque background?
• Does every value in the card layout have the right label?
• Are numbers right aligned, text left aligned and units in the headers?
• Does any status rely on color alone?
• Is zoom enabled, and are touch targets large enough?
• Did you test with a screen reader?

Each item is a small fix on its own. Together, however, they produce a table that truly works on a phone.

Who should build the table system on your site?

Fixing one table is usually easy. The challenge starts on sites where different editors add tables across hundreds of pages. There, the lasting solution is to build the table component at template level. The scroll container, caption field, header scopes and card layout then come built in. Editors only enter the data, and the structure always comes out right.

We build this setup on your site. We review your data heavy pages, choose the right pattern for each table type, add the component to your theme and complete accessibility testing. To define the scope, you can send a quote request through our web design page. We then prepare a tailored quote based on page count and table variety.

To sum up, a good mobile table combines the right pattern, the right HTML structure and testing on real devices. Skip these three steps and the table looks great on desktop but fails on a phone. Whatever pattern you choose, first ask what readers look for in the table.