Responsive Data Tables: A Comprehensive List of Solutions

Tables are an important part of HTML. Although they were often used in the past for layout, today they’re mainly used for marking up data. Since the adoption of responsive web design, various approaches have been developed for establishing tables that can scale well in different viewport sizes.

In this article, I’ll go over and analyze many of these approaches. Keep in mind that I’ll be focused mostly on the JavaScript-based ones, as I think they offer more options and features compared to the pure CSS solutions. To make things easier and clearer, this article is full of helpful images and demos.

The Basic Markup for Our Table

Before diving into the core methods, let’s have a look at the example table that will be used throughout this article to demonstrate the different methods for achieving responsive tables:

<table summary="Example table">
  <caption>Example Table Caption</caption>
      <th>Median Age</th>
      <th>Area (Km²)</th>
    <!-- more rows here... -->
      <td colspan="5">
      <!-- content here... -->

Note that with the exception of the Foundation example, the styling of this table will be based on Bootstrap’s table styles.

Let’s now get familiar with different techniques for building responsive tables.

Bootstrap’s Responsive Tables

To create a responsive table with Bootstrap, you have to wrap the table inside a div element with a class of table-responsive. By default, Bootstrap applies the overflow-x: auto property to this wrapper element. When the browser window is less than 768px, the overflow-y: hidden property is applied. Therefore, on small devices you can see the contents of your tables by scrolling horizontally.

The following screenshot demonstrates what’s described above:


View the CodePen demo using Bootstrap

Foundation’s Responsive Tables

Foundation provides an interesting way for creating responsive tables. As you can see in the next screenshot, on small devices (<767px) the first column (i.e. Country) is pinned to the left of the table, while the other ones are horizontally scrollable:


This solution isn’t part of Foundation’s default package, so if you want to include it in your projects, you should download the required JavaScript and CSS files from the corresponding page. Then all you have to do is to add the responsive class to your tables.

View the CodePen demo using Foundation


Stacktable.js is a jQuery plugin that changes the layout of your tables on small screens. Depending on the browser viewport, it toggles between two tables, the original table and a copy of it. The latter is a key/value table, where the key is a column name and the value is the row’s related value. As the following screenshot shows, this happens for all the columns except the first one:


The stacktable.js plugin requires jQuery, a JavaScript file, and a simple CSS file. After you add these files to your project, simply call the plugin on your desired table. By default, the initial table is hidden when the viewport has a width less than or equal to 800px. But, if you want, you can easily customize that.

View the CodePen demo using stacktable.js


Tablesaw is a set of jQuery plugins for responsive tables built by the Filament Group. Let’s have a closer look at some of these plugins.

Similar to, but not to be confused with the Stacktable.js plugin described above, Tablesaw offers its own implementation for creating key/value tables through a plugin called Stack Table. Here’s how it looks:


To use this plugin, you have to grab a copy of the required JavaScript and CSS files and include them in your project. Then, add the tablesaw and tablesaw-stack classes as well as the data-tablesaw-mode="stack" attribute to the desired tables. When the viewport has a width less than 640px, your tables will be optimized for responsive layouts.

View the CodePen demo using Tablesaw

But Tablesaw’s plugins can do more! First, the Toggle plugin helps you select which columns you want to be visible on different sizes. The Mini Map plugin gives users a clear view of the visible and hidden columns.

Again, you have to download the necessary files (e.g. tablesaw.bare.css). As a next step, select the breakpoints at which your columns will show. To do this, add the data-tablesaw-priority attribute to your table headers with the desired number or keyword as the value. Here’s an example:


Finally, invoke the functionality of the plugins by setting the related classes and attributes to your tables:

<table data-tablesaw-mode="columntoggle" data-tablesaw-minimap>

View the CodePen demo using Tablesaw with Toggle and Mini Map


RWD-Table-Patterns is an alternative implementation of the Tablesaw approach (see previous section). In addition, it’s designed to be used with Bootstrap, but feel free to customize it for different frameworks.

Before trying to use the plugin, make sure that you have successfully added all the required dependencies to your projects. You can initialize it by setting up Bootstrap’s structure (see the Bootstrap section above) and then assigning the data-pattern="priority-columns" attribute to the wrapper element. There’s also the option to specify the breakpoints at which your tables will be visible. To do so, add the data-priority attribute to the table headers with a desired value. Here’s how the plugin works:


Furthermore, by default, the table headers are fixed. Minify the viewport to test it!

View the CodePen demo using RWD-Table-Patterns


FooTable is another excellent solution for effectively scaling your tables across different screen sizes. It optionally provides useful add-ons like filtering, sorting, and pagination. Beyond its jQuery version, there’s also a WordPress plugin version.

As always, before using FooTable, you have to download the required files. You can do that by visiting the Footable GitHub repository.

To make that work, first assign the footable class to the desired table and then initialize the plugin via JavaScript. You have the option to customize the breakpoints at which your columns will be hidden. This can be achieved by adding the data-hide attribute to the corresponding table headers with the default values (e.g. phone,tablet) or custom keywords. The screenshot below gives you an idea of how it works.


Note also that the breakpoints are based on the table width. If you want to use the viewport width, you have to modify the configuration object.

View the CodePen demo using FooTable


DataTables is a well-known jQuery plugin useful to anyone who wants to work with HTML tables. Beyond its core powerful features, it provides an extension that allows you to build responsive tables. Depending on your front-end framework, different styling assets are required to integrate the plugin into your projects.

For instance, a project based on Bootstrap requires dependencies that can be found at this location. Once downloaded, you can initialize the responsive behavior by adding the dt-responsive class to the corresponding table and calling the extension on it.

Keep in mind that the plugin executes an automatic column hiding, but you can also apply your own customizations. Here’s how a table based on DataTable’s solution would look:


View the CodePen demo using DataTables

Pure CSS Solutions

As you probably noticed, all the solutions (apart from Bootstrap’s approach) presented above are JavaScript- or jQuery-based. However, there’s also a plethora of interesting plain CSS approaches. The list below summarizes a few of the most popular ones:

It’s worth mentioning that some of these were the basis for the development of most of the aforementioned JavaScript-based solutions.

Choosing the Right Method

At this point you might be wondering which one of these techniques/plugins you should use. Well, there’s no correct answer to this question. Before deciding, you have to take into consideration different factors. For instance:

  • The type of your data and its size/length. Say, for example, that you have tables with many columns. In that case, you might want to avoid having horizontal scrolling.
  • Do you need a simple or a more complex solution? Are you interested in features like filtering and/or sorting?
  • Is your data coming from an external data source (e.g. a web service)?


In this article, I presented different approaches you can follow to optimize your tables for small devices. I hope this helped you expand your knowledge and understanding of the solutions available. If you have ever used other techniques that I haven’t covered here, let us know in the comments below. Also, I encourage you to have a look at two other valuable resources on the same subject:

Finally, we’ve created a CodePen collection with all the demos from this article so you can check that out if you like.


I was hoping to see a comparison with the new ng responsive tables that are suppose to be very fast.


Well, I made this responsive tables plugin called Tabella.js and I can't tolerate it was ignored in this article smile take a look if you want


Your tfoot is in the wrong place. The tfoot must come before the first tbody as when printing out on paper the tfoot needs to print on every page and depending on where on the page the table starts you don't know how many rows of tbody will appear before the first print of the first tfoot.


As far as I know, with HTML5 you can place your tfoot either before tbody or after it. Previous versions, require tfoot before tbody. See the link.


Yes I noticed that the other day.It seemed a strange thing to change unless they assumed that most people were doing it wrong anyway.


How is the tbody supposed to print in the right place if it comes after the tbody. Each time there is a page break inside the tbody there is no tfoot data to print if the tfoot is at the bottom.

Presumably a tfoot at the bottom is simply treated as another tbody since it can't print at the bottom of every page the way it could if it were correctly positioned at the top.

For the next standard let's declare pi equal to 3. That will work just as well as allowing the tbody to go at the bottom where it will not be available until long after it is needed.


Firefox seems to handle tfoot after the tbody the same as if it were after thead. That is it prints the footer and header on each printed page either way. (I'm sure it must take a lot more processing to do that.)

It seems a silly thing to change to me.


Yes - it means that it has to do a double pass through the HTML so as to get the tfoot before it starts processing the tbody.

Even if it works it would slow the loading of the page while it gets the tfoot from where ever it is lower down in the HTML.

If browsers look for the tfoot further down the source then presumably always including a tfoot (even if empty) just after the thead would speed up the loading of the page as then it doesn't need to read the table twice.


The summary attribute on the table element is obsolete (


Yeah, that's true, yet many people still using it (see for example Foundation's docs). I could have omitted it as I have already defined a caption.


Thank you, a useful list of options.

I tried using TableSaw yesterday (before seeing this article) but it wasn't all that easy, and it made nonsense of my table because it dropped all my column headings (days of the week). If it were possible to avoid that I failed to work out how.

My table is a calendar, with days of the week horizontally and months vertically. Allowing for different start days, it comes out at about 38 columns wide (most of them narrow, fortunately). All the data comes from a MySQL DB via PHP, so my solution was simply to make an entirely new set of tables (one per month), each only one week wide. It only added about 80 lines of code to the existing PHP. Finally a media query to hide/display the appropriate table(s).

I'm sure there are times when a plug-in will be a better solution, but let's not forget there are others. See it at:


But the spec is wrong about that -- its obsolete status is based on a misunderstanding of its purpose.

The summary attribute should describe the structure of the table, while the caption describes its content. A data table should have both.

So in this example, the summary would be something like "This table has a row for each country, and a column for each piece of data about that country".

You should also have "scope" attributes on the TH cells smile

And I would strongly advise against that Foundation solution, because it has poor accessibility -- splitting the table into two tables where the headers in one are undisplayed and the data in the other is undisplayed, means that a screenreader can't get coherent data from either of the tables. The same applies to any solution that splits and hides the table content -- the integrity of the data structure must be maintained.


Here is one i picked up on google without any framework


        <th>First Name</th>
        <th>Last Name</th>
        <th>Job Title</th>
        <td>Chief Sandwich Eater</td>
        <td>Crimefighter Sorta</td>

The CSS:

Generic Styling, for Desktops/Laptops 
table { 
  width: 100%; 
  border-collapse: collapse; 
/* Zebra striping */
tr:nth-of-type(odd) { 
  background: #eee; 
th { 
  background: #333; 
  color: white; 
  font-weight: bold; 
td, th { 
  padding: 6px; 
  border: 1px solid #ccc; 
  text-align: left; 

The Media Queries:

Max width before this PARTICULAR table gets nasty
This query will take effect for any screen smaller than 760px
and also iPads specifically.
only screen and (max-width: 760px),
(min-device-width: 768px) and (max-device-width: 1024px)  {

    /* Force table to not be like tables anymore */
    table, thead, tbody, th, td, tr { 
        display: block; 
    /* Hide table headers (but not display: none;, for accessibility) */
    thead tr { 
        position: absolute;
        top: -9999px;
        left: -9999px;
    tr { border: 1px solid #ccc; }
    td { 
        /* Behave  like a "row" */
        border: none;
        border-bottom: 1px solid #eee; 
        position: relative;
        padding-left: 50%; 
    td:before { 
        /* Now like a table header */
        position: absolute;
        /* Top/left values mimic padding */
        top: 6px;
        left: 6px;
        width: 45%; 
        padding-right: 10px; 
        white-space: nowrap;
    Label the data
    td:nth-of-type(1):before { content: "First Name"; }
    td:nth-of-type(2):before { content: "Last Name"; }
    td:nth-of-type(3):before { content: "Job Title"; }
    td:nth-of-type(4):before { content: "Favorite Color"; }
    td:nth-of-type(5):before { content: "Wars of Trek?"; }
    td:nth-of-type(6):before { content: "Porn Name"; }
    td:nth-of-type(7):before { content: "Date of Birth"; }
    td:nth-of-type(8):before { content: "Dream Vacation City"; }
    td:nth-of-type(9):before { content: "GPA"; }
    td:nth-of-type(10):before { content: "Arbitrary Data"; }



I agree that Foundation's responsive table solution is a usability fail. First, on a recent version of an iphone, you don't see any visual cue that you can independently scroll on the first long cell vs the rest of the cells.

Second, the markup removes the table caption, which serves a purpose for screen readers and accessibility.

The Google solution is intriguing, and I found something similar here:


Yeah that's basically the approach I take too, except that I prefer to code the table headers into data attributes, then you can define them in a single CSS rule without having to specify content in the stylesheet, i.e:

<td data-header="First Name">James</td>


td::before { content:attr(data-header); }

Yes I use the similar method mentioned by brothercake but you should note that the table-cells in ie9 and under do not collapse in to blocks and break the layout.

The solution is pretty easy and you also need to set the td,tr,th, to float:left and width:100% and then IE9 and ie8 can play also smile


  table, thead, tbody, th, td, tr { 
        display: block; 

The display:block then becomes redundant but I leave it in anyway in case the float gets removed by accident.


Yeah right, and if you play with the floats and widths you can usually get away without needing absolute positioning (i.e. float the pseudo-element to the left of the TD content, rather than absolutely positioning it).

Another approach is to use display:table on each TD and then display:table-cell on the pseudo-element (or, wrap the TD content in a SPAN, and then use display:table-cell on both the pseudo-element and the SPAN, to give you more control). Though that only really works in IE9 or later.

Could probably do it with flexbox too, but I've never tried that smile