To display multiple lines in one Markdown table cell, keep the row on one source line and insert <br> between phrases. This works where tables and inline HTML are supported; check Obsidian and your destination renderer before relying on it.

This guide covers a practical Mac desktop task: writing a small table in Obsidian, checking its appearance, and preparing the same Markdown for GitHub or another renderer. The examples use synthetic stationery descriptions. The compatibility checks below are a workflow derived from the documentation, rather than results from testing installed applications.

Which Markdown renderers support multiline table cells?

Pipe tables are an extension, not part of core CommonMark. GitHub Flavored Markdown, or GFM, adds tables whose cells accept inline content. Its specification excludes block elements inside those cells. Consequently, a cell containing several displayed lines is different from a cell containing separate paragraphs, a Markdown list, or a fenced code block. See the GFM table specification.

Obsidian documents pipe tables and formatting within cells. Its basic syntax documentation also identifies <br> as a line-break tag. Together, these provide the documented basis for the approach used here, although the table page does not give a dedicated multiline-cell example. See Advanced formatting syntax and Basic formatting syntax.

Use this decision table before editing a large document:

Destination Documented boundary Practical choice
Core CommonMark without extensions Pipe tables are outside the core syntax Use headings and lists
GFM-compatible renderer Tables accept inline content, with no block elements inside cells Try an inline break and check the destination
Obsidian Tables and the line-break tag are documented Edit the source, then inspect Reading view
Renderer with unknown HTML handling Its support has not been established Run the small comparison below before choosing a format

The first three rows follow the CommonMark specification, GFM specification, and Obsidian documentation linked above. The final row is a recommended verification step: a renderer’s name alone does not establish how it handles your document.

How do you write two lines inside one cell?

Copy the following example into a note without copying the surrounding code fence. Each table row occupies one physical source line; the break marker sits between the two phrases in the second cell.

| Item | Details |
| --- | --- |
| Notebook | Dotted pages<br>Blue cover |
| Pencil | Graphite core<br>Hexagonal shape |

The intended result is a two-column table with two data rows. In the first details cell, “Dotted pages” appears above “Blue cover.” In the second, “Graphite core” appears above “Hexagonal shape.” This is an expected rendering to verify, not an embedded demonstration of your destination’s behavior.

The mechanism combines an inline HTML break with table syntax. GitHub documents an HTML line-break tag among its supported ways to create line breaks, while Obsidian explicitly documents <br>. These are HTML-assisted Markdown cells, so their portability depends on the destination accepting that markup. See GitHub’s line-break documentation and Obsidian’s basic syntax documentation.

Keep the table structure simple: include a blank line before it, use matching header and separator columns, and use three hyphens per separator cell. GitHub’s table guide documents the blank line and three-hyphen convention. Obsidian accepts at least two hyphens, so three is a useful shared choice. Sources: Organizing information with tables and Advanced formatting syntax.

Why don’t Enter, two spaces, or a backslash solve this?

CommonMark supports hard line breaks using two trailing spaces or a backslash before a source newline. Those rules concern inline content within an existing block; they do not define multiline pipe-table cells. See CommonMark’s hard line breaks.

For example, this is deliberately unsuitable for keeping both phrases inside one GFM cell:

| Item | Details |
| --- | --- |
| Notebook | Dotted pages
Blue cover |

Under GFM’s table rules, the second source line is another row rather than a continuation of the details cell. A blank line would end the table. Keep the complete row together and place the inline break where the displayed line should change. See the GFM table examples.

Also distinguish automatic wrapping from an intentional break. For this task, success means the second phrase starts on a new line even when the window is wide enough to fit both phrases. A narrow-window screenshot alone would not establish that.

How do you check the table in Obsidian on a Mac?

Use a temporary note containing just the sample table. This makes it easier to identify whether a problem comes from the table itself or its surrounding content.

  1. Switch the note to Source mode using the editing-mode status control. This mode exposes the Markdown exactly as written.
  2. Paste the sample and confirm that each data row remains on one source line.
  3. Press Cmd+E to switch between editing and Reading view.
  4. Inspect both details cells: each should contain two displayed lines, and neither phrase should have moved into a new table row.
  5. Return to editing and compare the result in Live Preview as well.

Obsidian documents Source mode, Live Preview, and the Mac shortcut in Views and editing mode. Live Preview hides much of the syntax while you edit; Reading view provides a useful separate check of the formatted note.

For a side-by-side comparison, hold Cmd while clicking the view switcher to open editing and reading views together. If that control is hidden, Obsidian documents Settings → Appearance → Show tab title bar, and an alternative status-bar control under Settings → Editor → Show editing mode in status bar. See Views and editing mode.

Obsidian’s basic syntax guide describes Shift+Enter for paragraph line breaks and a Strict Line Breaks setting. Those general paragraph instructions do not establish a portable table-cell shortcut. For this check, inspect the saved row in Source mode and use the explicit break marker rather than treating the setting as a table compatibility fix. See Basic formatting syntax.

How can you diagnose renderer differences quickly?

Use a plain-text control alongside the proposed multiline version. The following complete test document changes only the break marker, making it easier to separate table support from inline HTML support:

Control:

| Item | Details |
| --- | --- |
| Notebook | Dotted pages; blue cover |

Multiline candidate:

| Item | Details |
| --- | --- |
| Notebook | Dotted pages<br>Blue cover |

Open the same content in each intended destination. For a GitHub Markdown file, inspect its rendered file view; an Obsidian preview establishes only the Obsidian result. GitHub also documents different ordinary paragraph-newline behavior between Markdown files and conversation fields, reinforcing the value of checking the actual destination. See Basic writing and formatting syntax.

Use these observations to decide what to inspect next:

Observation Next check
Both examples show as pipe-delimited text Confirm table support and check that the content is outside a code fence
Control works, but the candidate prints the tag Check whether the tag was placed inside backticks or escaped
Control works, but the candidate loses its break Consult the destination’s inline HTML documentation
Candidate creates an additional row Inspect the source for an actual newline within the intended row
A phrase disappears or moves columns Look for an unescaped pipe in the cell content

These are diagnostic branches, not definitive explanations for every renderer. Repair the smallest sample first, then reintroduce the rest of the table. For literal pipes in cell text, GitHub documents escaping them with a backslash, as in Dotted \| plain. See Formatting content within your table.

What should you use when multiline cells are unsupported?

If the destination accepts tables but rejects inline HTML, use one row per detail. Repeating the item name preserves the association without requiring an in-cell break:

| Item | Detail |
| --- | --- |
| Notebook | Dotted pages |
| Notebook | Blue cover |

If the destination supports only core CommonMark, move the details into a heading and list:

### Notebook

- Dotted pages
- Blue cover

Headings and lists belong to the CommonMark syntax. This fallback also gives longer entries room to grow without depending on a table extension.

For multiline code, place a fenced code block outside the table. Wrapping several source lines in a single inline code span does not preserve their line breaks: CommonMark normalizes code-span line endings to spaces. See Code spans.

Choose the format according to the content you need to preserve. For two short phrases, an inline break is a practical candidate to verify. For separate paragraphs, substantial lists, or multiline code, move the detail outside the cell. Keep the small compatibility sample with your working notes so you can repeat the check whenever the destination changes.

Sources