Same symbols, different rules

Most tools where people type short messages offer chat formatting: a small set of Markdown-like markers, typed in the message box, that the app turns into bold, italic, code or links. It looks like Markdown, and the apps often call it that, but each has its own list of markers and its own rules. None of them is CommonMark.

Two differences cause most of the confusion. First, the meaning of a single asterisk: italic in Markdown, bold in Slack and Teams. Second, line breaks: in a chat message every line break is kept, while in a Markdown file a single newline is only a soft break and lines are joined.

You type Markdown (CommonMark/GFM) Slack message Teams chat
*text* italic bold bold
**text** bold see note below not in Microsoft's list
_text_ italic italic italic
~text~ strikethrough in GFM; text in CommonMark strikethrough strikethrough
# Heading heading no headings heading (levels 1–3)
Table with pipes table (GFM) no tables not in Microsoft's list
Single line break joined into one line new line new line

The table describes Slack's message format for apps and the Teams chat box as documented by Slack and Microsoft (as of October 2026). Both companies change their editors regularly, so try a marker before you rely on it.

Here is what Markdown makes of a message written in chat style. The single asterisks become italic, and the single tildes stay as they are, because markdown-it, like most renderers, only treats a double tilde as strikethrough:

*Portal back online.* Incident ~open~ resolved.
<p><em>Portal back online.</em> Incident ~open~ resolved.</p>

Slack

Slack mrkdwn (spelled without vowels, on purpose) is the formatting syntax Slack uses for message text sent by apps and integrations through its API. It has *bold*, _italic_, ~strikethrough~, `code`, code blocks with three backticks, > quotes, and lines starting with - to mimic lists (mrkdwn has no real list syntax), but no headings and no tables. Links are written in angle brackets with a pipe: <https://status.example.com|status page>. Because <, > and & mark links and mentions, an app must escape them in ordinary text.

*Portal degraded* since 14:05 UTC.
Logins fail for _some_ customers. Updates on the <https://status.example.com|status page>.
> Next update at 14:45.
Portal degraded since 14:05 UTC.
Logins fail for some customers. Updates on the status page.
▎Next update at 14:45.

Paste that same message into a Markdown file and it falls apart: the bold becomes italic, the lines are joined, and the Slack link is not a link at all, because a space is not allowed inside an autolink, so the angle brackets are just text:

*Portal degraded* since 14:05 UTC.
Logins fail for _some_ customers. Updates on the <https://status.example.com|status page>.
> Next update at 14:45.
<p><em>Portal degraded</em> since 14:05 UTC.
Logins fail for <em>some</em> customers. Updates on the &lt;https://status.example.com|status page&gt;.</p>
<blockquote>
<p>Next update at 14:45.</p>
</blockquote>

Slack also offers a separate markdown block for apps, which accepts standard Markdown, including headings and tables. Slack describes it as meant for apps that show answers from AI models, which are usually written in Markdown. How the message box treats what a person types (for example **double asterisks**) depends on the Slack client and its settings, so check it in your own workspace.

Microsoft Teams and Discord

Teams chat understands *bold*, _italic_, ~strikethrough~, headings with # to ###, numbered and bulleted lists, inline code, code blocks, [text](url) links and > quotes, and shows a preview in the compose box. Microsoft's own support page warns that, although it calls this Markdown, "it doesn't fully match standard Markdown". Messages sent by bots and apps in Adaptive Cards support an even smaller subset: bold, italic, lists and links, but no headings, tables or images.

Discord's chat formatting is closer to Markdown: it is reported to support **bold**, *italic*, ~~strikethrough~~, code, quotes, lists, masked links [text](url) and headings up to level 3, plus extras such as __underline__ and ||spoiler||. Headings and lists arrived in 2023. Discord's own help article could not be checked for this page, so treat the details as indicative.

Tickets and wikis: Jira and Confluence

In Jira Cloud and Confluence Cloud, Markdown is a typing shortcut. Type **bold**, ## at the start of a line or three backticks, and the Atlassian editor turns it into formatting as you type. Atlassian's documentation lists bold, italic, strikethrough, inline code, headings, lists, quotes, horizontal rules and code blocks. What is stored, however, is rich text, not Markdown: Atlassian states that you can copy raw Markdown into the editor but cannot convert content back into raw Markdown.

Two practical consequences for service desk and operations work:

  • Writing a ticket note in Markdown is fine; the editor converts it. But a runbook that has to live in Git as Markdown should be written there, not in a ticket or wiki page and copied over later.
  • Older instructions show Jira's legacy wiki markup (h1., {code}, *bold*). The new Jira Cloud editor does not use it; Atlassian has said it prefers Markdown across Jira, Confluence and Bitbucket Cloud. Self-managed Jira installations and older fields may still use wiki markup, so check which one your tool expects.

For what a good ticket note contains, whatever the format, see writing tickets.

Note-taking apps

A note-taking app is a program for collecting and organizing personal or team notes, with search, links between notes and often tags. Some, such as Obsidian, store each note as an ordinary .md file in a folder you control. Your notes then stay readable without the app, can be put in Git, and can be opened in any editor. Others, such as Notion, store notes in their own database and offer Markdown as an import and export format: Notion imports .md files and exports pages as Markdown, but features it does not know are lost on the way in.

Obsidian says it supports CommonMark, GitHub Flavored Markdown and LaTeX math, and it adds extras of its own. The most important is the wikilink: a link to another note written as the note's name in double square brackets, such as [[Portal runbook]], optionally with display text after a pipe. You do not need to know the file's path, and Obsidian can update the links when you rename a note.

Shift notes 2026-10-02 (Tomasz)

- BGP session to the backup ISP flapped twice, see [[Backup ISP]].
- Follow the [[Core switch replacement|switch runbook]] on Thursday.
- ==Ask Emeka to review the VLAN plan.==

> [!warning] Change freeze
> No changes on the core during the billing run.
Shift notes 2026-10-02 (Tomasz)
• BGP session to the backup ISP flapped twice, see Backup ISP.
• Follow the switch runbook on Thursday.
• [highlighted] Ask Emeka to review the VLAN plan.
┃ ⚠ Change freeze
┃ No changes on the core during the billing run.

Outside Obsidian, these extras are just text. A CommonMark renderer shows the brackets, the == markers and the [!warning] label literally:

- BGP session flapped twice, see [[Backup ISP]].
- Follow the [[Core switch replacement|switch runbook]] on Thursday.
- ==Ask Emeka to review the VLAN plan.==

> [!warning] Change freeze
> No changes on the core during the billing run.
<ul>
<li>BGP session flapped twice, see [[Backup ISP]].</li>
<li>Follow the [[Core switch replacement|switch runbook]] on Thursday.</li>
<li>==Ask Emeka to review the VLAN plan.==</li>
</ul>
<blockquote>
<p>[!warning] Change freeze
No changes on the core during the billing run.</p>
</blockquote>

Obsidian's callouts look like GitHub alerts but are not the same feature: Obsidian has more types and lets callouts fold and nest, so a note that renders nicely in Obsidian may need editing before it works on GitHub. Note properties (title, tags, dates) sit at the top of the file as front matter.

Copy and paste between tools

Much formatting trouble comes from the clipboard. When you copy from a web page, a rendered Markdown preview, Word or an email, the clipboard usually holds two versions: formatted text (HTML or rich text) and plain text. The app you paste into chooses one. Rich text paste is pasting the formatted version: fonts, colors, links and hidden markup come along, and the text is no longer what you copied in the source.

Three things that typically go wrong:

  • Commands lose their straight quotes. Word, email programs and renderers with "smart" typography replace " and ' with curly quotes and a free-standing -- with a dash. A shell does not accept those.
  • Markdown source pasted into a rich text field (an email, a Word document, some ticket fields) shows the raw ** and ##.
  • Rendered text pasted into a Markdown file loses its structure: a list becomes lines, links lose their address.

The quotes problem in action. With the "typographer" option, which some sites switch on for nicer prose, a command in normal text gets curly quotes (a shell then no longer sees one quoted search term); the same command in backticks is left alone:

Run grep -i "login failed" --count on the log.

Run `grep -i "login failed" --count` on the log.
<p>Run grep -i “login failed” --count on the log.</p>
<p>Run <code>grep -i &quot;login failed&quot; --count</code> on the log.</p>

AI assistants and Markdown

Chat assistants built on large language models usually answer in Markdown: headings, bullet lists, code fences and tables. Their chat window renders it, so you see formatted text. The trouble starts when you copy the answer somewhere else. A typical answer, rendered:

### Likely cause

The TLS certificate on **portal-login** expired at 02:00 UTC.

### Next steps

1. Check the expiry date:

   ```bash
   openssl x509 -enddate -noout -in portal-login.pem
   ```

2. Renew the certificate (see the runbook).
<h3>Likely cause</h3>
<p>The TLS certificate on <strong>portal-login</strong> expired at 02:00 UTC.</p>
<h3>Next steps</h3>
<ol>
<li>
<p>Check the expiry date:</p>
<pre><code class="language-bash">openssl x509 -enddate -noout -in portal-login.pem
</code></pre>
</li>
<li>
<p>Renew the certificate (see the runbook).</p>
</li>
</ol>

Practical rules when you use AI output:

  • Ask for the format the target needs. "Answer as plain text for a ticket note", "Slack format", or "a Markdown file with one H1" works better than cleaning up stray ### and ** afterward. See writing prompts.
  • Paste as Markdown only where Markdown is rendered: a .md file, a GitHub comment, Slack's markdown block. Elsewhere, copy the rendered text or ask for plain text.
  • Check the content, not just the formatting. Neat headings and a confident tone say nothing about whether the command is right; verify it before it goes into a runbook (see checking AI output). And never paste logs with customer data or secrets into an assistant to get them formatted (see what never to paste).

Writing for where it lands

Before you format anything, ask where the text will be read, and in what:

Destination Write
.md file in a repository Full Markdown for the platform (GitHub, GitLab, the docs site); hard breaks with \
GitHub or GitLab comment GFM; every Enter is a line break
Slack or Teams message Short lines, *bold*, - lists, backticks for code; no headings or tables
Jira or Confluence Markdown shortcuts while typing, or the editor's toolbar; keep the master copy of runbooks in Git
Email or Word No Markdown symbols; use the editor's formatting, or convert with Pandoc

When Amara Okafor of the service desk copies a status update from the NOC chat into the incident ticket, the bold first line and the short list survive almost everywhere. A heading, a table or a wikilink would not. Writing for the lowest common denominator where text travels, and for the full flavor where it stays, avoids almost all of these problems.