The short answer is that identical .md source does not promise identical pixels. Markdown records document structure, while each service chooses the font, spacing, colors, and reading width used to display that structure.
Most differences come from four layers: the syntax a parser recognizes, extensions such as GitHub Flavored Markdown, the CSS used for presentation, and security rules for raw HTML and remote resources. Separating these layers helps distinguish a broken file from a valid document rendered under different rules.
For an important document, the practical goal is portable meaning rather than identical styling everywhere. Use widely supported structure, then preview the final delivery environment.
Separate syntax, extensions, styling, and security policy
The same heading and paragraph can change size, spacing, color, and line length under another site's CSS.
They depend on extensions such as GitHub Flavored Markdown and may fall back to plain text elsewhere.
A different base path, blocked remote image, or sanitized HTML element can make content appear to be missing.
Compare one small source sample across three views
- 1
Find a short part of the MD containing the difference: a heading, single line break, table, task list, relative image, or raw HTML.
- 2
Inspect the source as text first. Confirm that copying or automatic formatting did not change spaces, blank lines, or punctuation.
- 3
Render the same section in GitHub or its authoring service, a general Markdown viewer, and the final exported format.
- 4
Classify the difference as parser syntax, extension support, CSS, base path, or security filtering.
- 5
Optimize for the recipient's final environment, simplify the syntax or repair asset paths, and preview again.
CommonMark defines a baseline; GFM adds features
Early Markdown descriptions left edge cases open to interpretation. CommonMark specifies core elements such as headings, paragraphs, lists, links, and code more precisely, but services can still use different versions and options.
GitHub Flavored Markdown builds on CommonMark with tables, task lists, strikethrough, and extended autolinks. If a GitHub table becomes text containing pipe characters in a simpler renderer, extension support is a more likely cause than file corruption.
| Source element | CommonMark core | GFM extension | Why it may differ |
|---|---|---|---|
| # heading, paragraph, list | Yes | Yes | Mostly styling differences |
| ``` fenced code | Yes | Yes | Syntax highlighting and CSS vary |
| | table | | No | Yes | Falls back to ordinary text without the extension |
| - [ ] task | No | Yes | Checkbox conversion depends on the renderer |
| ~~strikethrough~~ | No | Yes | Extension and delimiter rules vary |
One Enter key can remain a line break inside a paragraph
Under CommonMark, an ordinary line ending inside a paragraph is a soft break. A renderer may display it like a space, so two source lines can appear as one flowing sentence.
Use a blank line for a clear new paragraph. CommonMark also supports a hard line break with two trailing spaces or a backslash, but invisible trailing spaces can be removed during editing. If a team relies on them, document the convention.
- New paragraph: one blank line between blocks
- Hard break within one paragraph: two trailing spaces or a backslash
- Renderer option: some services turn every soft break into a visible break
Markdown stores structure; CSS controls appearance
An MD file usually does not say that a heading is 28 pixels or the article is 760 pixels wide. The renderer converts a heading to h1, a paragraph to p, and code to pre; the site's CSS then supplies fonts, sizes, spacing, backgrounds, borders, and maximum width.
A code block can be narrow and gray on GitHub but wide and dark in another viewer. If the heading hierarchy and code content remain intact, this is a presentation difference rather than changed content. When a fixed appearance matters for print or submission, finalize and inspect a PDF in the target workflow.
Relative paths change with the document's location
 does not embed photo data. It instructs the renderer to find a separate asset relative to the current document. GitHub can resolve that path against the repository file and branch, while a web viewer given only one MD file cannot access a neighboring folder automatically.
GitHub recommends relative links for files and images that live inside a repository. If you are emailing one MD file or creating a standalone HTML, PDF, or DOCX, keep the assets together, use an accessible full URL where appropriate, or verify that the export actually contains the image. The right path strategy depends on the delivery unit.
Valid raw HTML is not a promise that a service will execute it
CommonMark recognizes some raw HTML syntax. A real service can still remove or escape scripts, iframes, event attributes, forms, and selected elements for security. That is a security decision rather than necessarily a Markdown parsing error.
Remote images create a similar tradeoff. Displaying one sends a browser request to the image host, so a privacy-focused viewer may block it until the user opts in. Portable documents should not depend on unsafe HTML or a remote resource to communicate their essential meaning.
A practical standard for portable Markdown
Use basic headings, paragraphs, lists, links, and fenced code for essential structure. When a table, task list, or strikethrough depends on an extension, make sure the surrounding words still communicate the result in a renderer that lacks it. Raw HTML used for color or spacing creates avoidable platform dependence.
Instead of demanding pixel identity, verify heading hierarchy, paragraph order, list items, link destinations, code content, and image meaning. Previewing the actual destination remains the only reliable way to confirm a submission or handoff.
- Write essential content with the CommonMark baseline
- Confirm GFM support before relying on tables, tasks, or strikethrough
- Ship relative assets together with the MD file
- Keep the core message understandable without raw HTML or remote resources
- Preview the widest table and longest code line in the delivery environment
Official documentation used for this analysis
Different styling is not necessarily a content error
The same Markdown most often looks different because parsers, GFM extensions, CSS, path context, and security rules differ—not because the file is damaged. Classifying the difference first avoids unnecessary rewriting and conversion.
For broad sharing, build the essential structure with baseline syntax and treat extensions and images as features that need verification. For an important handoff, preview the destination and then create the appropriate HTML, PDF, or DOCX copy.