Update: I've just enabled this feature network-wide. All sites across Stack Exchange are now able to use tables. Thanks for all the feedback. We'll keep monitoring this question and we'll continue to iron out some of the rough edges.

No waffling, right to the point:

What? When? Where?
Table support 2020-11-23 Meta Stack Exchange & DBA Meta
More table support week of 2020-11-30 DBA Stack Exchange
Even more table support week of 2020-12-07 Network-wide launch (if no major issues found)

That's right. It's finally time to support table syntax in our Markdown dialect. This has been a long-requested feature and we're happy that we can finally do something about it. Starting today you can include tables in your posts using the GitHub-flavored Markdown table syntax.

In the past, we've been hesitant to introduce table syntax to our Markdown dialect. One reason was the lack of a good standard. There are various formats floating around the web but there hasn't been a well-defined standard for a long time. CommonMark still doesn't specify tables in version 0.29.

Another major reason was that tables are hard to pull off. If done poorly, there's a risk that rogue tables ruin the entire page layout for our users. And turning a bunch of markdown into proper tables has always been a scary task when we still maintained our own markdown renderers.

A lot of time has passed and it's time to re-evaluate our concerns.

Switching to CommonMark is paying its dividends: The newly introduced open source Markdown renderers support table syntax and we can rely on them to handle this tricky task incredibly well.

The uncertainty around a well-specified table syntax hasn't completely gone away. Ideally, we'd use the official CommonMark syntax, if only there was one. However, we think that GitHub-flavored markdown offers a table syntax that's stable and usable enough to serve our purpose.

And finally, this is another case where we can happily promote a Stack Overflow for Teams feature to be used by all our network sites. When building Articles for Teams our Teams users let us know that table support is crucial for their documentation purposes. This request was one of the major triggers behind the whole CommonMark migration and supporting table syntax today.

Note: our usual holiday build freeze starts end of day Tuesday, November 24th. We want to start collecting feedback early but we won’t be able to address any issues until Monday Nov 30th, after Thanksgiving. If something’s going horribly wrong, we will disable the feature again (but let’s hope for the best!).


Okay, so how do you use tables? We've updated our formatting help to give you some guidance. But here's an overview for you.

A simple table looks like this:

| A header | Another header |
| -------- | -------------- |
| First    | row            |
| Second   | row            |

The result:

A header Another header
First row
Second row

The rules

  • You always need a header row

  • Cells are separated by a pipe (|) symbol

  • You can include leading and trailing pipes but don't have to

  • A header row has to be followed by a separator row with the same amount of cells, and you can't have spaces between separators (- characters)

    (that's the |---|---| line)

  • The amount of space and - characters in a cell don't have to line up (but it sure looks nice if it does)

  • You can set the alignment of a table column by including a : in the corresponding cell of the separator line. A : on the left will make a column left-aligned (this is the default). A : on the right will make it right-aligned. Both, left and right :s will produce a center-aligned column.

    | left | center | right |
    |:---- |:------:| -----:|
    | One  | Two    | Three |
    left center right
    One Two Three


Markdown tables come with a set of limitations. They don't support everything you can do with HTML tables, and that's on purpose. Each cell can only include inline content (text, images, links, inline code).

You can't merge cells or rows.

Block content like multiple paragraphs, lists, code blocks, sub-tables and other complex stuff does not work. If you're trying to mix a Markdown table with inline HTML, you might be up for a wild ride.

You can't manually determine the width of a column. Your browser will decide what's a good width for any given column based on the content in your table.

If you need more details, I recommend taking a peek at the GitHub-flavored Markdown specification for tables.

Roll-out plan

Teams users have been able to use tables in their posts for a few weeks now, so nothing's changing over there.

Starting 2020-11-23 we're going to enable table support for Meta Stack Exchange and our table-loving friends over at DBA Meta Stack Exchange so you can start playing around with the feature, get familiar with the syntax and help us weed out some issues we have missed.

The plan is to enable tables on DBA Stack Exchange the week of 2020-11-30 if there's no feedback or concerns suggesting this was a bad idea.

After that, we're letting the feature sink in for a bit and gather more feedback before rolling it out network-wide to all sites across the Stack Exchange network. We're hoping to roll it out the week of 2020-12-07.


I found a bug. What should I do?

This is great! We know that table support can still have some rough edges. Please add an answer to this announcement that reproduces the issue you've found (if possible) and we'll investigate.

What took you so long?

The amount of effort to build and maintain our own renderer when we still built our own Markdown renderers made this change prohibitively expensive. Teams customers asking for this feature allowed us to spent time on fundamentally revamping our Markdown rendering functionality and to get all the foundations in place to finally support tables.

What happens if CommonMark adopts an official table syntax in the future?

We're trying to be as CommonMark compliant as we can be, so chances are we're going to support the CommonMark syntax if that ever happened. Our Markdown renderers (markdown-it and Markdig) both comply to the CommonMark specification. Most likely, it would be a matter of time until they adopted an official CommonMark table syntax. If they did, we could update both libraries to introduce the same syntax on the Stack Exchange network. If we ever get to that point, we'll know more details and can think through all the details.

Why did you choose the GitHub-flavored syntax over <my favorite syntax>?

GitHub-flavored Markdown's ("GFM") table syntax has a reasonable specification. It's working for other significant sites on the web. Our Markdown renderers support GFM-style tables out of the box. It was the most pragmatic choice from our point of view.

Will tables show up properly in the live preview?

Yes. Our live preview below the editor will render the tables as you type.

We've got some more refinements around inserting and editing tables lined up that we'll release in the next few weeks.

  • 87
    Is there a plan to add a table button (wizard, csv converter, something?) to the editor for those... less fluent in md? – Nick Nov 23 '20 at 17:22
  • 13
    Timely advice to readers, the easiest way is writing your tables in a spreadsheet and exporting in one of the markdown supported formats. – bad_coder Nov 23 '20 at 18:03
  • 5
    @Ollie Clearly, we're so excited about them, we don't want to let you hide them! :P (My guess, they're both not CommonMark, so they don't play well together) Feel free to post as an answer – Catija Nov 23 '20 at 18:11
  • 3
    There are a few table posts now in the Formatting Sandbox, e.g. this one highlighting a few differences between preview and finished post — and of course the usual sandbox weirdness. – Sebastian Simon Nov 23 '20 at 18:23
  • 5
    "Holiday build freeze on november 24th". Can I also get 5 weeks of christmas holidays please? – Luuklag Nov 23 '20 at 18:56
  • 2
    @Luuklag It's just until Monday the 30th of November. – Catija Nov 23 '20 at 19:02
  • 32
    @Nick yes, we're going to include buttons for inserting and editing tables in the new editor that we're going to present soon. Tables are complicated so we'll likely need a few iterations to get this right but I think this will be a step in the right direction. – Ham Vocke Nov 23 '20 at 19:07
  • 4
    @Catija, too bad. I guess there is another Americanocentric holiday the world has to suffer ;) – Luuklag Nov 23 '20 at 19:20
  • 4
    Thanks for implementing this. It might be quite handy in some situations. "Teams customers asking for this ..." That made me realize that this community here should have stronger ties to the Teams user community. That way whenever we want something we should tell Teams users how wonderful that would be for Teams first. :) – Trilarion Nov 24 '20 at 14:58
  • 5
    What holiday is this? My Google search for "November 24 holiday" only found the National Sardines Day. Is this for real? – Emil Jeřábek Nov 24 '20 at 16:05
  • 7
    @EmilJeřábek US - Thanksgiving. It's on Thursday the 26th. It's also not on a specific date, but the fourth Thursday of November. – Catija Nov 24 '20 at 16:09
  • 6
    @EmilJeřábek I must admit that National Sardines Day is a bit... of a fishy reason to take a vacation. – Journeyman Geek Nov 25 '20 at 9:44
  • 8
    @AndrewGrimm what kind of disability are we talking about? The HTML tables we're generating are using proper semantics and should work reasonably well for users who are using screen readers. A lot of care goes into our Stacks design system to make sure the colors and fonts we use work for visually impaired users. Accessibility is hard and we don't always get it right, but we're trying. If you notice something specific that's not accessible, please let us know. – Ham Vocke Dec 4 '20 at 11:11
  • 5
    @DavidConrad I get why this is confusing. Let me try to clarify: CommonMark is a popular markdown specification. Switching to CommonMark allowed us to replace our old, hand-rolled Markdown renderers with something off the shelve. CommonMark does not define tables (yet?). The open source renderers we introduced, however, support more than just CommonMark (GFM tables for example). That's the causality. Switching to CommonMark brought us open source renderers and they brought table support. – Ham Vocke Dec 11 '20 at 7:50
  • 6
    @TheTechExpertGuy That's not really how Community Wikis work. A CW is a signal that the post is open to editing and contributions from all people who wish to participate. It's not a way to shelter from rep gains. Additionally, this is an important release that Ham led and getting some reputation for that and taking the time to announce and support the release is... totally fair. We do not use CW for announcements. That would be a huge departure from our standards. This is also a big change, which is why it's been featured for a while, but "a pretty long time" is just a week, not so long. – Catija Dec 11 '20 at 14:24

38 Answers 38


Using the mobile version of the site, some columns can be too thin and thus impossible to read its content. See this post:

The original table is this:

App versions  Free? Description
Diccionario de la lengua española
by RAE and ASALE
Duolingo Android
Windows Phone
yes app to help you learn Spanish with game-like lessons
(similar a Memrise)
yes se basa en tarjetas que contienen una palabra/expresión/oración en un idioma y su traducción a otro idioma. La frecuencia con la que te sale cada tarjeta depende de tu facilidad para memorizarla, que tú seleccionas una vez destapas la tarjeta. De esta manera practicas las palabras que te cuestan más. Para saber más, consulta esta respuesta.
Speed Spanish Android yes app with multiple tools and games to help user's learn Spanish, including: Dictionary, translator, conjugator, lessons & multiplayer games. Developed by Kes Walker

From my mobile phone I see it as follows. You can reproduce it by switching to the mobile version of the site and reducing the screen to the minimum:

enter image description here

As you can see, the first column is extremely thin. I don't know why it does not take more space and all of it is given to the 4th column.

  • 6
    Yeah, unfortunately the browser's default layouting algorithm can be annoying, especially on small viewports. Our Stacks folks got a basic version for responsive tables up their sleeves but last time I checked they were still struggling with a few edge cases. Once we get that in, tables should start scrolling horizontally on narrow viewports if they exceed a minimum width. – Ham Vocke Dec 10 '20 at 13:16
  • 1
    @HamVocke that's good news. Thanks for being so supportive – fedorqui 'SO stop harming' Dec 10 '20 at 13:48
  • 3
    I checked in with our Stacks folks and it turns out I was wrong. Tables do start scrolling if they need to on small viewports already. However, this isn't available in the mobile view of the page but only in the responsive view. Make sure to choose "full site" and "enable responsiveness" in the footer to switch. – Ham Vocke Dec 11 '20 at 8:02

Do the displayed tables have to be full width?

Or, more accurately, when a table is simple and small, as (for example), in this SQL question on Stack Overflow, it would be nicer to my way of thinking if the tables did not expand to the full width.

The tables there are:

ID Name
157 Bob
157 James
300 Phil
300 Keith
300 Paul


ID Name
157 Bob, James
300 Phil, Keith, Paul

In my opinion, neither table benefits from being expanded to the width of a browser window on a big monitor.

This is an image of a narrower version of the tables (obtained by shrinking a Chrome window to its minimum width), but the final result could be a lot narrower still for these tables.

Shrunken version of the tables, but the final result could be narrower still

I'm not a web programmer (you mean, there are things called 'user interfaces'? I had no idea!), so I'm not sure what this request entails.


Enabled network-wide? Well, not entirely... One small network of indomitable chatters still holds out against the invaders.

This doesn't work in chat. Can we get updates for chat too please?

  • 5
    Why would you want to insert a giant table in chat? – Cody Gray Dec 18 '20 at 6:26
  • 1
    I said nothing about "giant", just a table. – Squirrelkiller Dec 18 '20 at 7:20
  • 2
    Let me try again: tables are for presenting long-form information. Why would you want to do this in chat? How would this be useful? – Cody Gray Dec 18 '20 at 7:33
  • 6
    @CodyGray Same reason multi-line code snippets work in chat? Markdown support should be as consistent as possible, so that I don't have to remember which features don't work in chat/comments/questions/answers/… – Bergi Dec 18 '20 at 11:00

When viewing a table as a reader, add an option to display the table full screen (or at the least some larger view), since it is quite annoying to do the horizontal scrolling for wide tables.

Example of table for which a larger view would be beneficial:

Row # Date Action Stock A price Stock A cost basis Gain/loss Commutative Gain/loss Taxed Commutative Gains Cumulative Taxed Commutative Gains
1 2020-02-07 Buy 100 of stock A 10 10 0 0 0 0
2 2020-03-17 Sell 100 of stock A 20 20 1000 1000 1000 1000
3 2020-03-22 Buy 100 of stock A 18 18 0 1000 0 1000
4 2020-03-29 Sell 100 of stock A 3 3 -1500 -500 -1500 -500
5 2020-04-10 Buy 50 of stock A 2 2 + (18-3) = 17 0 -500 1500*(50/100)=750 250
6 2020-04-15 Sell 50 of stock A 3 3 50 -450 (3-17)*50=-700 -450
7 2020-05-15 No activity on stock A 3 NA 0 -450 0 -450

A larger view is much more readable:

enter image description here


It is cool! Thx! ;)

I have a question. How will it be combined with the new WYSIWYG editor?

  • 2
    Yes, they will be there. Just a wysiwyg table in the post. – Qwertiy Dec 14 '20 at 21:05
  • @Qwertiy Thx! ;) – Victor VosMottor Dec 15 '20 at 11:24

You might want to support colspan.

Right now, only MultiMarkdown does, I believe. See this SO question for a good test case.

The answer in that particular case, eg, is this:

| Available  |||| Process   | Allocation    ||||     Max      ||||
| A | B | C | D |           |   A | B | C | D  | A | B | C | D   |
| 1 | 5 | 2 | 0 | P0        |   0 | 0 | 1 | 2  | 0 | 0 | 1 | 2   |
|            |||| P1        |   1 | 0 | 0 | 0  | 1 | 7 | 5 | 0   |
|            |||| P2        |   1 | 3 | 5 | 4  | 2 | 3 | 5 | 6   |
|            |||| P3        |   0 | 6 | 3 | 2  | 0 | 6 | 5 | 2   |
|            |||| P4        |   0 | 0 | 1 | 4  | 0 | 6 | 5 | 6   |

You can see results in different renderers at BabelMark.

Only MultiMarkdown includes the expected/intended colspans.

screenshot of table code as rendered by MultiMarkdown

For @shog9, this isn't better than the MultiMarkdown, above. It's better to have a non-destructive shortcut for colspans than to use html, I believe. That is, MMD tables are a clean superset of GFM tables.

    <th colspan="4"> Available </th>
    <th> Process </th>
    <th colspan="4"> Allocation </th>
    <th colspan="4">  Max  </th>

    <td> A </td>
    <td> B </td>
    <td> C </td>
    <td> D </td>
    <td>   </td>
    <td> A </td>
    <td> B </td>
    <td> C </td>
    <td> D </td>
    <td> A </td>
    <td> B </td>
    <td> C </td>
    <td> D </td>
    <td> 1 </td>
    <td> 5 </td>
    <td> 2 </td>
    <td> 0 </td>
    <td> P0  </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 1 </td>
    <td> 2 </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 1 </td>
    <td> 2 </td>
    <td colspan="4">   </td>
    <td> P1  </td>
    <td> 1 </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 1 </td>
    <td> 7 </td>
    <td> 5 </td>
    <td> 0 </td>
<!-- etc etc -->
  • 2
    I can't vouch whether this is in scope, but that's pretty cool! – zcoop98 Feb 9 at 15:56
  • 1
    For now, I don't see us supporting this. We're trying to stick to the CommonMark specification as close as possible and already make an exception with the current GitHub-flavored markdown table syntax because we found it's the syntax with the best support across markdown parsers. As nice as colspan support is, it's not something we can support in good faith any time soon. – Ham Vocke Feb 10 at 11:05
  • @HamVocke My hope was if you were already adding a non-standard extension to CommonMark you might as well go big so you can prevent the hassle of opening up a settled codebase later. That said, I haven't looked at Penney's source -- a quick glance this morning isn't comforting. – ruffin Feb 10 at 13:45
  • 3
    In my experience, the best part about GFM-style tables is that they look pretty nice in the source (or can, at least). Once that's not true anymore, you're better off just using raw HTML - it's more portable and just as unreadable. If SO was gonna support colspan/rowspan, I'd prefer they did so by supporting limited table HTML. – Shog9 Feb 10 at 15:17
  • @Shog9 I added the start of what the HTML code would be for that table. I realize this is edgy, but that table even as formatted in the MMD is much easier to scan as source than the table html, below. That is, I think I'd rather have this non-destructive "hidden" shortcut (ie, don't use or know about it? No changes to rest of the table format) for colspan than to support html table tags. That is, MMD tables are a clean superset of GFM tables. – ruffin Feb 10 at 18:21
  • I agree it remains pretty readable in your example, ruffin; that said, this example is well-suited for it: column heading text is consistently longer than column data. As data length grows, it gets harder and harder to look at the table source and understand what it represents; this is already an issue with even simple GFM tables when, say, an initial column contains lengthy text, as unlike normal Markdown content text cannot be wrapped to a readable length! HTML OTOH does not suffer from this issue, and as content complexity increases the verbose markup becomes less predominate. – Shog9 Feb 10 at 18:51
  • I think it's interesting here to contrast the Markdown table extensions with something like RST, which... Doesn't much bother with trying to make table sources look like tables, but does try to at least keep them readable and beyond that mostly focuses on ease of authoring (with CSV tables assuming the data is likely coming in from an external source anyway): sublime-and-sphinx-guide.readthedocs.io/en/latest/tables.html For these sites, that could mean recognizing that an awful lot of tabular data is coming from database tooling, CSV exports, or other structured formats. – Shog9 Feb 10 at 18:55
  • @Shog9 "I agree it remains pretty readable in your example; that said, this example is well-suited for it: column heading text is consistently longer than column data." Agreed. Cell wrapping is a big enough issue I tried to provide a fix by extending MMD tables with "multiline grids" in my app, but even those are quickly a huge pita to format. (I do want to revisit auto whitespace insertion for them tho). I like the table-as-list hack in RST. The limits of human readable text - I just don't know that html table tags are ever much better. /shrug – ruffin Feb 10 at 19:29
  • 2
    HTML tables are... Terribly unreadable, even when nicely formatted. Their advantage is simply widespread support: if not explicitly disallowed, they can at least work reliably on every parser. Lacking a clearly better solution for the general case, that at least is something! – Shog9 Feb 10 at 20:11

All text to the right of a table is ignored.

Column 1 Column 2 Column 3
1.1 1.2 1.3
2.1 2.2 2.3

I am not sure if this was done on purpose. If it is not a bug, adding this caveat in the post would be helpful.

How did I encounter this issue?

I was editing some posts on Stack Overflow with "hardcoded" tables (I don't know what's the term for manually typed tables) to use the new table feature. The posts had some text on the right of some rows. I then noticed after the table was visible in the preview, all that text disappeared.

I then had to do this:

Enter image description here

It was not the only post with such text on the right. IMO, allowing text on the right of tables can be useful sometimes, but it'll leave that to discussion.

  • 9
    That's on purpose. We can't really show text next to a table that's not part of the table itself due to the way table syntax is specified and the parser handles things. I can imagine two workarounds: (1) Make the "note" part of an extra column that you specify as part of the table syntax, or (2) highlight the row in question (e.g. in bold or with an asterisk/dagger character) and reference that in a note below the table. – Ham Vocke Jan 6 at 15:49

Add ability to convert the image of a table into Markdown.

E.g., an image of a table =

Enter image description here

Markdown =

| ASR API      | Date       |CV    | F   | IER | LS-c| LS-o |
| :---         | :---: | :---: | :---: | :---: | :---: | :---: |
| Human        |  |  | | | 5.8| 12.7
| Google       | 2018-03-30 | 23.2 | 24.2| 16.6| 12.1| 28.8
| Google Cloud | 2018-03-30 | 23.3 | 26.3| 18.3| 12.3| 27.3
| IBM          | 2018-03-30 | 21.8 | 47.6| 24.0|  9.8| 25.3
| Microsoft    | 2018-06-30 | 29.1 | 28.1| 23.1| 18.8| 35.9
| Speechmatics | 2018-09-12 | 19.1 | 38.4| 21.4|  7.3| 19.4
| Wit.ai       | 2018-01-03 | 35.6 | 54.2| 37.4| 19.2| 41.7

Motivation of my request: one of my answers, containing the image of a table, got downvoted a few times because people wanted the Markdown version instead. The conversion is quite easy to do with OCR + table recognition for simple tables.

  • 1
    tag wiki for status-deferred says it can only be applied by moderators and developers. – Kodos Johnson Dec 30 '20 at 21:47
  • @KodosJohnson thank you, sorry I mistakenly added it. – Franck Dernoncourt Dec 30 '20 at 21:50
  • 9
    Honestly not sure how we could ever do this. It'd require a very complicated image recognition system that we simply don't have. – Catija Dec 30 '20 at 23:17
  • If this is as simple as you suggest, you're best served by providing a light-weight, open source solution they can just plug and play. Makes for an easier pitch internally if you do a little of that leg work for them. – canon Jan 13 at 19:45
  • @Catija there's a free API, which is worth investigating, if SE will decide such a feature is helpful enough. – Shadow The Vaccinated Wizard Feb 9 at 16:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .