Markdown variants: more than one standard
Markdown was created by John Gruber in 2004 as a way to write HTML using simpler syntax. The original spec was minimal and ambiguous in many corner cases, which led to incompatible variants: CommonMark (the most formal spec, used by Stack Overflow), GitHub Flavored Markdown (CommonMark plus tables, task lists, strikethrough, autolinks), Reddit's variant (no tables, custom syntax for spoilers), and dozens of others.
This tool uses GitHub Flavored Markdown by default — the variant most developers actually write. Tables, fenced code blocks with language hints, task lists with - [x], strikethrough with ~~text~~, and automatic URL linking all work.
GFM features worth knowing
### Tables (pipes + alignment) | Column A | Column B | Column C | |----------|:--------:|---------:| | left | center | right | ### Task lists - [x] done thing - [ ] todo thing ### Fenced code with language ```js const greet = name => 'hello ' + name; ``` ### Strikethrough ~~struck through~~ ### Autolink https://example.com works without [text](url)
Going the other direction: HTML → Markdown
Converting HTML back to Markdown is "lossy" because HTML can express things Markdown can't (style attributes, classes, custom elements, nested structures). This tool uses Turndown — it preserves the structure Markdown supports (headings, paragraphs, lists, links, images, code, blockquotes, emphasis) and drops everything else.
Use cases: extracting documentation from a website, converting rich-text editor output to plain Markdown for storage, normalizing HTML pasted from various sources into a consistent format.
What this tool doesn't do
- Render rich previews of GitHub-specific features like alerts (
> [!NOTE]), mermaid diagrams, or footnote backreferences. The conversion produces correct HTML; the visual rendering on GitHub.com adds custom CSS we don't replicate here. - Sanitize HTML for safety. If you're rendering user-submitted Markdown on a site, you MUST run the HTML output through a sanitizer like DOMPurify before inserting it into the page.
markedby itself accepts inline HTML, which is an XSS vector. - Preserve semantic HTML on round-trips. Convert HTML → Markdown → HTML and you may get different (but visually equivalent) markup.
<strong>may become<b>, attributes may be lost.
Common use cases
- Preview Markdown before committing to a README
- Convert HTML pasted from a CMS back to clean Markdown
- Extract documentation from an HTML page
- Verify your Markdown renders the same locally as on GitHub
Frequently asked questions
Is the HTML output safe to render directly?
No. <code>marked</code> by default accepts inline HTML, which can include scripts. Always run the output through a sanitizer like DOMPurify before inserting into a page that displays user-controlled Markdown.
Why does my HTML → Markdown round-trip lose styling?
Markdown can't express every HTML feature. Inline styles, classes, custom data attributes, and complex layouts get dropped. Round-trips preserve <em>semantic structure</em> (headings, lists, links, code) but not <em>presentation</em>.
GitHub renders my Markdown differently than this tool.
GitHub uses a custom Markdown variant (GFM + GitHub-specific extensions like alerts, mermaid, autolinking of issue refs). This tool implements standard GFM but not the GitHub-only features. For final preview, test on a real PR.
Can I use this for blog posts in a CMS?
Yes — write in Markdown locally, convert to HTML here, paste into your CMS. Workflow used by many devs to avoid CMS-specific WYSIWYG editors.