Markdown was described in 2004 as a way of writing that reads well as plain text and converts to HTML. The description was informal and left a great many cases undefined, so every implementation resolved them differently and all of them called the result Markdown.
Two decades later there are two things worth knowing about, and the difference between them explains almost every surprise.
CommonMark and GitHub Flavored Markdown
CommonMark is a precise specification with a test suite, written to settle the ambiguities. It defines exactly what happens with nested lists, with emphasis inside words, with a list interrupted by a paragraph — the cases that used to differ between tools.
GitHub Flavored Markdown is CommonMark plus four additions people now assume are core: tables, strikethrough, task lists and automatic linking of bare URLs.
That last point is the practical one. Tables are an extension. A converter implementing CommonMark faithfully will render your table as a paragraph full of pipe characters, and it is not wrong.
What every converter agrees on
Headings with hashes, paragraphs separated by blank lines, emphasis with asterisks or underscores, ordered and unordered lists, links and images in bracket-parenthesis form, blockquotes, inline code with backticks, fenced code blocks, and horizontal rules.
That is the portable subset. Anything written with only those converts identically everywhere, and it covers most documents.
What varies
Tables, strikethrough, task lists, autolinks — GFM extensions. Widely supported and not universal.
Footnotes, definition lists, abbreviations — extensions from other dialects, supported by fewer tools.
Front matter — the YAML block at the top of a file. Not Markdown at all; a convention that static site generators strip before parsing. A general converter renders it as a paragraph with a horizontal rule above it.
Raw HTML — passed through by most, stripped by anything sanitising, and the right behaviour depends entirely on where the Markdown came from.
Line breaks, the recurring confusion
A single newline is a space. Markdown reflows paragraphs, so a sentence split across three lines in your editor becomes one line of prose.
A blank line starts a new paragraph. To break a line within a paragraph, end it with two spaces or a backslash.
The two-space rule is invisible in every editor, which is why it causes so much trouble — trailing whitespace trimmers remove it silently, and the document changes shape with no visible edit. The backslash is uglier and survives.
Converting the other way
HTML to Markdown works and is lossy in a specific way: anything Markdown has no syntax for is dropped. Classes, inline styles, most attributes, and deeply nested structure all flatten.
So a round trip does not return the original. That is fine when the point is to extract readable text from a page — which is the usual reason — and it is worth knowing before using it as a storage format.
Where the output goes
A converter gives you a fragment, not a document — headings and paragraphs, no <html>, no head, no styling. That is usually what you want, since it is going into a template.
If it is being published, two things follow. Anything containing user-written Markdown needs sanitising, because raw HTML passes through by default and a script tag is raw HTML. And the fragment needs a stylesheet — unstyled headings and lists look like a document from 1995, which is why converted output so often looks unfinished.
The short version
Stick to the portable subset and it converts identically everywhere. Tables and task lists are GFM extensions, so check what your converter implements before assuming something is broken. And remember that a single newline is a space — most surprises are that.