Markdown ↔ HTML Converter

Markdown and HTML are the two formats that almost every text-driven product juggles between. Markdown is what humans write — README files, blog posts, GitHub comments, Slack messages, documentation pages, in-app notes — because it is fast to type, looks readable in raw form, and rewards muscle memory once you have learned its handful of conventions. HTML is what browsers, email clients, and rendering engines actually consume; it is the canonical form a Markdown document gets compiled to before anyone sees it. The conversion happens hundreds of millions of times a day across the web, mostly invisibly, and the friction surfaces only when something goes wrong: a Markdown table that does not render, an HTML email that you want to edit in Markdown, a CMS that imports HTML and exports it back as broken Markdown, a documentation tool that supports one format but not the other.

This converter handles both directions of that conversion with a single interface. Paste Markdown on the left, get HTML on the right, and vice versa. The Markdown side speaks CommonMark (the standardized variant) plus GitHub Flavored Markdown extensions: tables, task lists with [ ] and [x] checkboxes, fenced code blocks with language tags, autolinked URLs, strikethrough with ~~text~~, and footnotes. The HTML side uses a tolerant parser based on the same engine GitHub uses to render comments, which means it forgives the kind of imperfect HTML you actually encounter in the wild — unclosed tags, mismatched quotes, weird whitespace — instead of silently producing garbage when the input is not pristine. The parser converts to a clean Markdown representation that round-trips back to equivalent HTML when you flip the direction.

The Markdown-to-HTML direction is the simpler of the two and the one most users want. Headings (# H1, ## H2) become <h1>, <h2>. Paragraphs separated by blank lines become <p>. Bold (text) becomes <strong>, italic (*text*) becomes <em>. Links (label) become <a> tags. Code spans (`code`) become <code>, fenced code blocks (```language) become <pre><code class="language-...">. Lists (- item or 1. item) become <ul> or <ol>. Block quotes (> text) become <blockquote>. The transformations are deterministic and the output is well-formed HTML5 with sensible attribute defaults. Code blocks support optional syntax highlighting via inline class names that pair with common highlighter libraries (Prism, highlight.js); the highlighting itself happens at the rendering layer, but the class names this tool emits are compatible with both.

GFM tables are worth a separate mention because they are the feature that makes Markdown actually work for documentation. The pipe-and-dash syntax produces clean <table>, <thead>, <tbody>, and aligned columns based on the colon position in the separator row. Tables that have a header row produce semantically correct markup that screen readers handle well, and the alignment metadata translates to inline style or class-based alignment depending on your preference. Tables with merged cells are not part of the GFM spec and not handled — if you need merged cells, you have outgrown Markdown for that document and should hand-write the HTML directly. Most documentation tables fit comfortably within the simple-grid model.

Task lists are the second extension that makes Markdown ergonomic for product work. The syntax `- [ ] not done` and `- [x] done` becomes <li> elements with embedded checkbox <input> tags, marked checked or unchecked based on the bracket content. The output checkboxes are disabled by default in raw HTML (so they render as visual indicators rather than interactive form controls), which matches how GitHub renders them in issue comments. If you want interactive checkboxes for a wiki or note-taking app, post-process the output to remove the disabled attribute; the conversion preserves enough structure that a single line of replace logic does it.

Sanitization is one of the configurable knobs and matters when the Markdown comes from untrusted users. Plain Markdown allows raw HTML — `<script>alert(1)</script>` in a Markdown source produces a real <script> tag in the rendered output, which is an XSS vector if the rendered output is shown to other users. The sanitize toggle, when enabled, strips dangerous HTML tags and attributes (<script>, on* event handlers, javascript: URLs, data: URLs except for safe types like images) while preserving the safe Markdown markup. For first-party content (your own README, your own blog posts), sanitization is unnecessary and you can keep it off; for any user-generated content rendered into a shared page, it should be on. The default position depends on context.

The HTML-to-Markdown direction is the harder of the two because HTML is a superset — there are HTML constructs that have no clean Markdown representation, and the converter has to decide between approximating them in Markdown (lossy) or preserving the original HTML inline (preserves meaning but breaks the round-trip). The tool defaults to a balanced mode: preserve safe HTML inline when there is no clean Markdown equivalent (for instance, <details><summary> blocks become inline HTML in the Markdown output), and approximate when there is (a <span style='font-weight:bold'> becomes bold rather than being preserved). Inline styles are stripped because Markdown is a structural format and inline styles are presentational; if you need to preserve specific styling, the output Markdown will need post-processing or you should keep the source as HTML.

Link reference style is a configuration knob in the HTML-to-Markdown direction worth knowing about. Markdown links can be inline (text) or reference-style ([text][1] with [1]: url at the bottom of the document). Inline is more common and what most authors prefer for short documents; reference-style is cleaner for documents with many links because it separates the prose from the URLs. The HTML-to-Markdown converter can emit either, and the right choice depends on the destination — inline for blog posts, reference-style for long-form documentation that benefits from a 'links' section at the end. Most users never touch this setting; the inline default is right for the common case.

Smart quotes is another knob that catches authors out. Markdown source files typically use straight quotes (" and ') because that is what shipping keyboards have, but the rendered HTML often wants curly quotes (“, ”, ‘, ’) for typographic correctness. The smart-quotes toggle converts straight to curly during Markdown-to-HTML rendering, with the right contextual rules (opening vs closing, single vs double, apostrophes vs single-quotes-as-quotes). For technical writing — code snippets, API documentation, anything where the literal characters matter — keep smart quotes off; for prose writing, turn them on. The HTML-to-Markdown direction reverses curly back to straight if you want the source to be portable across rendering targets.

Code blocks deserve a final note because they are where most rendering surprises happen. Fenced code blocks with a language tag (```javascript) produce <pre><code class="language-javascript"> in the HTML output. Many syntax highlighters (Prism, highlight.js, Shiki at build time) read this class name to do the actual coloring; the converter does not run the highlighter itself, since highlighting is a rendering-time concern that depends on which highlighter you ship. Indented code blocks (four spaces or a tab) produce the same <pre><code> output but without a language class, which means no highlighting. Mixing fenced and indented styles in one document works but is best avoided. The HTML-to-Markdown direction round-trips fenced code blocks back to fenced syntax, preserving the language tag if the <code> element has a `language-*` class.

Operationally the tool is one workspace with the source text on the left, the converted output on the right, a direction-toggle button between them, and a row of toggles for the configuration knobs (sanitize, smart quotes, link reference style, GFM extensions). Both panels support live editing — change the source and the output updates instantly; change the output and the source updates in the reverse direction. Copy and download are one-click. Word and character counts on each side help you track length budgets when writing for a platform that has them. Sample documents are available for both directions to illustrate what good Markdown and good HTML look like in this tool's output.

Privacy is the same model as our other client-side tools: nothing is uploaded, nothing is logged, the conversion runs entirely in your browser using local JavaScript. The libraries that power the conversion (marked for Markdown-to-HTML, turndown for HTML-to-Markdown) are bundled with the page and run in the browser; no remote API call is made for any conversion. This matters when the content is sensitive — drafts of articles before they are published, internal documentation, anything you would not want flowing through a third-party server. The tool pairs naturally with the rest of Omnvert's writing utilities. The Word Counter gives you a deeper view of the linguistic shape of either direction, the JSON Viewer handles structured-data adjacent to Markdown documents, and the HTML Formatter is useful when the HTML side of the conversion needs to be cleaned up before pasting into a CMS.