Guide

How to Convert Markdown Tables to PDF Without Breaking

June 13, 2026 · 6 min read

You wrote a clean Markdown table. It looks perfect in your editor. Then you export to PDF and the last two columns are gone, sliced off at the right edge of the page, or a page break cuts a row clean in half so the header sits on one page and the data on the next.

This is the single most common failure when converting Markdown to PDF, and it is fixable. Here's why it happens and how to get sharp, complete tables every time.

A quick refresher on GFM table syntax

GitHub Flavored Markdown (GFM) tables are built from pipes (|) and a separator row of dashes. The separator row also controls column alignment:

:--- left-aligns the column
:---: centers it
---: right-aligns it

Here's the raw markup:

| Feature        | Free Plan | Pro Plan |
| :------------- | :-------: | -------: |
| Export to PDF  |    Yes    |      Yes |
| No watermark   |    Yes    |      Yes |
| Editable tables|    Yes    |      Yes |
| Price          |     $0    |       $0 |

And here is how that renders:

Feature	Free Plan	Pro Plan
Export to PDF	Yes	Yes
No watermark	Yes	Yes
Editable tables	Yes	Yes
Price	$0	$0

The alignment colons are cosmetic in your text editor but they carry through to the rendered table and the PDF, so use them to keep numbers right-aligned and labels left-aligned. That alone makes wide tables easier to read.

Why tables break in PDF

There are two separate problems, and they have different causes.

The table is wider than the printable page. A PDF page has a fixed width. An A4 page in portrait orientation gives you roughly 170mm of printable width once margins are subtracted. If your table's natural width exceeds that, a naive converter simply lets the content run off the right edge and clips whatever doesn't fit. You lose columns without any warning. This is the classic "where did my last column go" bug.

A page break lands in the middle of a row. Even a table that fits horizontally can break vertically. When a table is taller than the remaining space on a page, the converter has to continue it on the next page. If it splits at an arbitrary pixel, a single row gets torn across the boundary, leaving half a line of text stranded at the bottom of one page and the rest at the top of the next.

Both problems come down to the converter not respecting the page's physical constraints. Fix the constraints and the tables behave.

Solution 1: use a converter that respects the printable width

The most reliable fix is to let the tool do the work. The browser-based converter at ConvertMDapp constrains all content to the printable A4 width, so a table can never spill past the right margin and get clipped. It also applies avoid-break rules to table rows, which tells the layout engine not to slice a row across a page boundary. When a table is too tall for the current page, the whole next row moves to the following page intact.

Because it runs 100% in your browser, nothing you paste ever leaves your device. There's no signup, no watermark on the output, and it's free. Paste your Markdown, watch the live two-way preview, and export a clean PDF.

The editable-preview workflow matters most for tables. Click any table in the preview and you can add or delete rows and columns directly, without hunting through pipe characters in the raw text. So the loop is: paste your table, tweak it live until the columns fit and read well, then export. You see exactly what the PDF will contain before you generate it.

Solution 2: reduce or shorten your columns

If a table is fundamentally too wide, the content is the problem, not the tool. Trim it:

Cut columns you don't strictly need, or merge two related columns into one.
Shorten long headers. "Estimated Monthly Recurring Revenue" becomes "Est. MRR." Header text often sets the minimum column width, so shortening it can reclaim significant horizontal space.
Abbreviate repetitive cell values with a key or legend below the table.

Fewer, tighter columns fit the printable width without any other tricks.

Solution 3: shrink the font or switch to landscape

When you genuinely need every column, give the table more room:

A smaller body font lets more columns fit within the same printable width.
Landscape orientation swaps the page's width and height. On A4 that turns roughly 170mm of usable width into about 260mm, which is often enough to fit a table that overflows in portrait.

Landscape is the single biggest win for data-heavy tables, so reach for it before you start deleting columns.

Solution 4: split one wide table into two

If a table has many columns that fall into natural groups, split it. Keep a shared key column (an ID or a name) in both tables so readers can line up the rows, then move the remaining columns into a second table stacked below. Two readable tables beat one clipped one.

Solution 5: force a page break before a big table

Sometimes a large table starts near the bottom of a page, leaving only a couple of rows before the break. It reads better to push the whole table onto a fresh page. You can force a page break with a small HTML divider in your Markdown:

Some paragraph text before the table.

<div style="page-break-before: always;"></div>

| Column A | Column B |
| :------- | :------- |
| Value 1  | Value 2  |

The page-break-before: always rule moves everything after it to the top of the next page, giving your table a clean full-page run. This is general page-break control: you can use the same divider anywhere you want a hard break, not just before tables. Combined with the row avoid-break behavior, you get full command over where content lands.

Put it together

For most tables, one setting does it: use a converter that constrains content to the printable width and keeps rows intact. When a table is still too wide, go landscape, then trim columns or split the table, and use a forced page break to keep a big table off the bottom of a page.

The fastest way to get there is the editable live preview. Paste your Markdown, adjust the table in place until it looks right in the preview pane, toggle light or dark theme if you like, and export. The same approach works for any document with tables, including a GitHub README exported to PDF. For everything beyond tables, see the full guide to converting Markdown to PDF.

FAQ

Why is the right side of my table cut off in the PDF? The table is wider than the printable page width, and the converter clipped the overflow instead of scaling it. Use a tool that constrains content to the printable A4 width, switch to landscape, or reduce the number of columns.

How do I stop a table row from splitting across two pages? Use a converter that applies avoid-break rules to table rows, so a row that won't fit moves to the next page whole. ConvertMDapp does this automatically for every table.

Can I edit a Markdown table without touching the raw pipes? Yes. In the live preview, click the table and add or delete rows and columns directly, then export the PDF once it looks right.