Text to Markdown Table & FAQPage Schema Generator

Three things go wrong in hand-written Markdown tables, and none of them produce an error. A | inside a cell starts a new column, so A|B becomes two cells and your data quietly shifts. A newline inside a cell ends the row entirely. And a row with fewer cells than the header leaves a table that is not rectangular, which some renderers pad and some do not.

This tool escapes pipes as \|, turns newlines inside a cell into <br> rather than dropping them, and pads short rows to the width of the widest one. Crucially it does not fix them silently: when rows were padded, the notes tell you how many, because a row that was short a value is usually a mistake in the source data rather than something to paper over.

The delimiter is detected from whichever the text uses most — tabs for a spreadsheet paste, pipes for hand-written rows, commas for CSV, and runs of two or more spaces as a last resort. Single spaces are never treated as a delimiter, because the space between every pair of words in a sentence would otherwise turn any prose into a hundred-column table.

Column count comes from the widest row, not the first, so one extra cell does not truncate the rest. Alignment is read from a separator row when the input has one: --- means default, :--- left, ---: right and :---: centre. That is more specific than the dropdown, so it wins, and the dropdown only applies to tables with no separator row. Every column is padded to a common width, so the table lines up in a code block as well as on the page.

Read this before you build a strategy on it. Google only shows FAQ rich results for a small number of authoritative government and health sites. For an ordinary site, expect no stars, no expanded dropdowns and no traffic from it. The markup is still valid schema.org, still useful for screen readers and other consumers, and is what many third-party tools read — it is simply not a traffic lever for most publishers.

What is generated is a FAQPage with a mainEntity array of Question objects, each with an acceptedAnswer. Answer text continues past its A: marker until the next question and is joined into one paragraph, which is what the format expects. The page name is taken from your title field, or guessed from the first question if you leave it blank — and it should be set to the real page title, because the markup and the visible heading disagreeing is exactly the kind of inconsistency validators flag.

If you add the optional speakable block, it only does anything if you wrap each answer in an element with class="faq-answer" yourself. The schema cannot add that wrapper, and a selector pointing at elements that do not exist does nothing at all.

In auto mode the tool runs both detectors, and that creates a problem worth naming. A page that has a pricing table and then a list of questions is one piece of text, so a naive table parser reads the Q: and A: lines as two more rows of the table with one cell each. The result looks plausible and is completely wrong.

So the FAQ parser reports which lines it did not consume, and the table is built from that remainder. Everything before the first Q: becomes the table; the questions and answers become the schema. Choosing Table or FAQ mode explicitly bypasses this and uses the whole text, which is the right behaviour when the Q:/A: lines really are table data.

If the text contains fewer than two columns once split, and no question and answer pairs, there is nothing to convert, and the tool says so rather than producing a one-column table with a header and no data. The most common cause is a table pasted with single spaces between columns, which is not a format any Markdown parser can detect reliably. Use tabs, pipes or commas.

Everything runs on the server and nothing is sent anywhere, so pasting a draft pricing table or an unpublished FAQ does not put it on a third party's machine.