Lists or Tables?

Written 2026-06-24

When you have a set of multi-column data records (or structs, or objects, or whatever you call them), do you format it as a list or a table? This question has come up multiple times in my work recently, and I never had a clear answer. Let’s take a list of posts from this site as our first example. Each post has two columns, a title, and the date the post was written. The title is the primary focus, but I want to show the date to give readers a sense of time and to show how the list is sorted.

Sidenote: I am using the all: revert; CSS property for these examples to preserve their styling over time. I am also turning on horizontal scrolling for the examples to prevent bad wrapping on mobile screen sizes. Generally, tables will wrap worse than lists will, especially when you have a small number of columns. But once you get more complex lists, even they will get squashed at mobile sizes.

Example 1a: a post list with all columns merged together

This is exactly how I am currently displaying the posts on this site. It is very simple and feels easy enough to read. The main thing I want to point out is that this method does not align the second column horizontally. Since each post’s title has a differing length, each date ends up at a different position. For the reader, it is difficult to visually jump between the same column on different rows if they are not aligned.

I think it makes sense to use a list in this case because the dates are secondary information to the title, so it is okay if they are not aligned. Reader’s can scan the titles easily enough because they are aligned at the start, and then the reader can follow the line to read the date, only if they are intrigued by the title first.

For the sake of comparison, let’s see how I would format this list as a table.

Example 1b: a post table with two columns

I do not mind formatting even a simple list like this as a table, but it feels a bit unnecessary when you only have two columns. All the extra space between the shorter titles and the dates feels awkward to me. Let’s look at a more complex example where we have multiple columns with important information.

Example 2a: a class list with ~7 columns

Here is a list of class information with around 7 columns depending on how you are counting. I gave this version its best fighting chance by using nested lists for multiple instances of the same class on different dates. I also pulled the cost out and put it with the title, assuming the cost should be the same for each instance of the class, also knowing that the cost is the most important information second only to the class title.

I enjoy this style of formatting lists quite a bit (perhaps because I came up with it on my own), but I am also interested in how it could be formatted as a table.

Example 2b: a class table with ~7 columns

I gave the table the same treatment as the list by pulling titles and costs out into a separate “header” row. Even now, I am not sure which version I like better. The list looks more pleasing to me visually, but I think the table would be easier to scan through quickly. Plus, there is still some low hanging fruit for making the table look better if I were actually using it for a real project. You could right-align the dates and the location columns, and think about switching to a font with more consistent number alignment for the dates.

Both the list and the table are extremely information-dense, which goes against the current trend of adding white-space to everything. I think we do ourselves (and our users) a disservice though, if we automatically add white-space and reduce the information present on a page simply because that is the zeitgeist.

I have made websites where the information in the above table would have been spread out across multiple pages. It made sense for me to design the site that way at the time, but I think there was an alternate path where I could have concentrated the information into a list or table like the ones shown above, and provided a better experience for our users. Providing more information in the same place can dramatically reduce the amount of navigations the user has to endure.

It can also eliminate the need for more complicated features on your website. If your users have to click into a separate page to view the information above for each class, then they will ask you for the ability to search by class title, location, dates, and probably price. But, if you give your users a table or a list with all that important information already present, you are giving them the power to search and scan freely all on the same page. Information-dense UIs put power back into the hands of the users, which is good for your users, but also good for you.

Going back to the title of this post: lists or tables? My (boring) answer is both, and make them as information-dense and easy to read as you can. The choice depends so much on the number of columns you are displaying and the type of data within those columns.