
Your 12-page report opened as 14 on their machine. Here's why, and how to stop it.
28 July 2026

It renders beautifully on GitHub and reads as plain text everywhere else. Convert it.
Markdown converts to PDF by rendering the formatting syntax into actual styled output. Headings become headings, **bold** becomes bold, tables become tables. Sent as a raw .md file, it displays as plain text with asterisks and hashes visible, because only tools that understand Markdown render it.
Which is fine among developers and unhelpful with everyone else.
Because a .md file is a text file. The formatting is a convention, not a property of the file. GitHub, your editor, and documentation platforms interpret ## as a heading, and Notepad, Word, and most email clients do not.
Send a technical spec as Markdown to a client and they see:
## System Requirements
- **Minimum:** 8GB RAM
- **Recommended:** 16GB RAM
They read it, but they read it as marked-up text, and it signals a draft rather than a deliverable. Converting produces a document with real headings, real bold, and real bullets.
Standard Markdown, and the extended table syntax most people use:
| Syntax | Output |
|---|---|
# through ###### | Heading levels |
**bold**, *italic* | Styled text |
- and 1. | Bullet and numbered lists |
| ` | ` tables |
``` code blocks | Monospaced blocks |
[text](url) | Clickable links |
> | Block quotes |
Raw HTML embedded in Markdown is the ambiguous case. Some of it renders, some appears literally. If your file mixes HTML and Markdown heavily, check the output rather than assuming.
.md file.Free accounts handle files up to 100MB, which is far beyond any realistic Markdown document.
The pattern is always the same: content written in Markdown that has to reach someone outside the tooling that renders it.
Writers who work in Markdown by preference hit this constantly, the format is excellent for drafting and invisible to everyone downstream.
Local image references depend on relative paths, so an image at ./diagrams/architecture.png needs that file present when converting. Absolute URLs to hosted images are more reliable if you're converting a file that has moved from its original folder.
Links convert to clickable links. Internal anchors pointing to headings within the same document generally work; links to other Markdown files in the same repository will not, since those files don't exist in the PDF. If your document depends on cross-file navigation, consider combining the pieces first and converting once.
Yes, and it's a distinct use case. PDF to Markdown extracts a PDF into Markdown, which is useful for getting documentation into version control, feeding content into a static site generator, or preparing text for a system that expects Markdown input.
The round trip isn't lossless in either direction. Converting to PDF fixes the layout; converting back reconstructs structure by inference. Keep whichever version is your source of truth as the master.
Yes, rendered in a monospaced font as distinct blocks. Syntax highlighting depends on the rendering step and may come through as plain monospaced text rather than coloured, the structure is preserved either way.
Output uses a clean default layout suited to documents. For heavily branded material, converting to PDF and then applying your own treatment, or writing in a tool with custom templates. Gives more control than any conversion step will.
Length isn't a problem; pagination handles it. If the result is unwieldy, split it with Split PDF into sections that make sense to the reader.
Files transfer over encrypted connections and are permanently deleted within 15 minutes of processing unless you save them to your library.
Upload your .md to Markdown to PDF and check the tables in the output. They're the element most worth a second look.
Try it yourself

Your 12-page report opened as 14 on their machine. Here's why, and how to stop it.

PDFs have fixed pages. E-readers want text that reflows to the screen.

Ctrl+P captures cookie banners and misses images. Here's how to archive a page properly.