Markdown or plain text: choosing a handoff format

A model replies in Markdown, and the place it needs to land — an email, a form, a ticket system — usually takes only plain text. In the other direction, your own docs are Markdown and need to go into a CMS that speaks only HTML. Neither direction should require a build step.

Markdown to plain text is harder than it looks

Intuitively it is "strip a few symbols". The difficulty is links.

Removing asterisks from **important** is fine, but [docs](https://example.com) breaks in two different ways depending on how naive you are: keeping only the label loses information, while keeping the whole expression pushes a URL and its brackets into the middle of a sentence. The sensible rule is to keep the label and drop the address — a plain-text reader cannot click, and the URL is usually in the way.

Lists are the other common mistake. Drop the - and a list reads as prose; keep the indentation and the prefix and a reader still sees a list at a glance. Plain text does not mean abandoning structure — it means expressing structure with characters instead of styles.

Converting to HTML fails on the other side

The reverse direction does not lose data; it can leak it. Passing raw HTML through a Markdown converter is a well-known vector: a <script> in the source gets emitted into the target page.

So the correct default for HTML output is to escape inline HTML, emitting only the tags the converter itself generates. The result should be treated as text input, not as trusted markup — and that boundary belongs in the tool's documentation rather than in the user's assumptions.

Tables are the litmus test

If you want to check whether a converter is worth using, a table is enough. The Markdown converter is a useful reference: it handles escaped pipes and both output targets.

A Markdown table's separator row is a run of dashes and pipes, and cell content can contain a pipe as well. A naive implementation splits the whole row on the pipe, so a pipe inside a cell skews the grid. The robust approach evaluates the separator row character by character and skips escaped pipes while splitting.

The same question applies to plain text: does the table become paragraphs or stay as an aligned block? That depends on who is reading it downstream.

Do not let format become a decision point

One last suggestion, unrelated to tooling: do not make "which format" a fresh judgement every time.

Settle a default — machine-readable goes plain text, rendered pages get HTML — and let a converter carry the middle. Once format choice is re-decided per task, it gets skipped on some busy afternoon, and the cost usually surfaces a week later.

Pick the format the destination can consume. Follow the downstream capability, not the upstream preference — hand the conversion to a tool and stop making format a per-task decision.