Reference guide
Discord Markdown, without the guesswork.
Discord supports useful Markdown-like formatting, but it is not CommonMark or GitHub Flavored Markdown. This guide shows what works, what degrades, and what needs conversion.
01
Supported formatting
Discord renders emphasis, headings, quotes, lists, code, spoilers, and masked links. Exact nesting can still differ from CommonMark.
| Purpose | Syntax |
|---|---|
| Bold | **bold** |
| Italic | *italic* |
| Underline | __underline__ |
| Strikethrough | ~~old~~ |
| Spoiler | ||hidden|| |
| Heading | ### Heading |
| Quote | > quoted text |
| Inline code | `code` |
| Masked link | [label](https://example.com) |
02
What Discord does not support
Several common GitHub and documentation features do not have a native Discord equivalent.
- TablesConvert to an aligned code block or readable key/value rows.
- Task checkboxesUse
☑and☐instead of expecting interactive boxes. - Markdown imagesUse a visible or masked URL; image preview generation is not deterministic.
- LaTeX and MermaidPreserve the source in inline or fenced code.
- Footnotes and reference linksResolve them into ordinary links and notes.
- Raw HTMLFlatten safe readable content; Discord does not render arbitrary HTML.
03
The 2,000-character limit
Ordinary Discord message content is limited to 2,000 characters. A naïve substring split can break links, emphasis, lists, Unicode sequences, or fenced code.
A safe splitter prefers paragraph and list boundaries. When a code block must be divided, each message needs its own closing and opening fence with the same language identifier.
04
Mentions and safety
Generated text can contain @everyone, @here, or structured user and role mentions. Pasting that text may notify people unexpectedly.
Bot developers should restrict Discord's allowed_mentions payload. Copy-and-paste tools cannot control that API setting, so they should detect or neutralize notification-sensitive tokens by default.
05
Conversion recommendations
- Parse the source as CommonMark plus the GFM extensions you explicitly support.
- Transform the syntax tree instead of applying regular-expression replacements to the entire document.
- Resolve unsupported structures using documented, deterministic policies.
- Neutralize active mentions outside inert code spans.
- Split at structural boundaries and validate every output message independently.