WordPress Markdown: Write Posts in Markdown

WordPress markdown support comes in three forms. You can convert Markdown to HTML and paste it into a Custom HTML block, use the Jetpack Markdown block, or install a plugin that replaces the editor. This guide ranks the three routes by how much you install, pastes the same test post into each, and shows which elements survive.

What Does WordPress Markdown Mean?

The phrase covers three different things, and search results mix them up.

Writing posts in Markdown. You draft in Markdown and want it published on your own WordPress site. That's what most people mean, and it's what the three routes below solve.

The Jetpack Markdown block. A block inside the WordPress editor that accepts Markdown and renders it. It ships with Jetpack and is switched on by default on WordPress.com.

Markdown output from WordPress.org. Since March 2026, most WordPress.org project sites serve a Markdown version of their pages. Send an Accept: text/markdown header or add ?output_format=md to the URL, and the page head carries a link rel="alternate" type="text/markdown" tag for discovery. The announcement on make.wordpress.org is clear that this is about the WordPress.org sites themselves, not your self-hosted install.

If you want the third one on your own site, look at plugins such as LLM Markdown on the plugin directory. The rest of this post is about the first two.

Route 1: No Plugin, Convert Markdown to HTML and Paste

This WordPress Markdown route installs nothing. Draft in a Markdown editor, convert to HTML, paste the HTML into a Custom HTML block. It's the answer to the recurring forum question "is there a simple Markdown block?" from people who don't want Jetpack.

1. Write the post in the editor and check the live preview.
2. Run it through the Markdown to HTML converter and copy the output. The full conversion guide covers the other converters if you prefer a command line.
3. In the block editor, type /html in an empty paragraph and press Enter to insert a Custom HTML block.
4. Click Edit HTML, paste, and check the preview pane on the right. Press Update.

Since WordPress 7.0 the Custom HTML block has separate HTML, CSS, and JavaScript panels, per the block documentation. Two things to know: contributors without the unfiltered_html capability get their markup sanitised with wp_kses(), which strips tags such as script and iframe, and the block has no sidebar options. Everything in the HTML renders on the front end with your theme's styles.

You can also switch the whole editor to the Code editor view (three-dot menu, then Code editor) and paste the HTML there. That works, but the block editor then wraps everything in one Classic block, which is harder to edit later.

The trade-off is obvious: the post is stored as HTML, so future edits happen in HTML or in a fresh Markdown draft that you convert again. We prefer this route for long technical posts with tables and code, because nothing gets lost in translation.

Route 2: The Jetpack Markdown Block

If Jetpack is already installed, search for Markdown in the block inserter. It sits in the Jetpack section. Start typing Markdown inside the block. The block converts on save and shows the rendered result on the front end.

Enabling Markdown for whole posts depends on which kind of site you have. The WordPress.com support page lists these paths:

• WordPress.com sites without plugins: Settings, then Writing, then toggle Use Markdown for posts and pages.
• Sites with Jetpack (self-hosted or plugin-enabled): Jetpack, Settings, Writing tab, toggle Write posts or pages in plain-text Markdown syntax. For comments, use the Discussion tab and toggle Enable Markdown use for comments.
• Classic editor users: the block does not apply. Jetpack's Markdown support page points to a separate setup for the Classic editor.

Now the limitation, and it's the one that catches people. The WordPress.com documentation states that the block follows the CommonMark spec and does not support Markdown Extra. Markdown Extra is where tables, footnotes, and definition lists come from.

Jetpack's own page says the block uses the markdown-it parser, which can handle pipe tables and fenced code depending on how it's configured, but the official position is CommonMark only. Save a draft and check the front end before you rely on a table.

Route 3: A Dedicated Markdown Plugin

WordPress Markdown plugin roundups age badly. Two of the plugins recommended in most 2024 lists are gone. WP Githuber MD was closed on the plugin directory on 8 October 2024 for a security issue. WP Editor.md was closed on 9 April 2025 for the same reason. Iceberg no longer appears in the directory search. Don't install any of them from a third-party mirror.

Two plugins that are maintained as of September 2026:

Markup Markdown (1,000+ active installs, tested with WordPress 7.1, updated within the past week). It replaces the block editor with EasyMDE, a CodeMirror-based Markdown editor, stores Markdown in the database, and renders on the front end with the Parsedown library. The changelog mentions tables, fenced code, footnotes, task lists, and optional KaTeX or MathJax.

Ultimate Markdown (2,000+ active installs, tested with WordPress 7.1). It keeps the block editor and adds panels to import .md files, insert pasted Markdown, and export posts, using the League CommonMark parsers, with YAML front matter for post settings.

Both change how your content is stored, so test on a staging site and export your Markdown before switching plugins. A plugin that goes unmaintained can leave you with posts stored in a format your site can no longer render.

Which Markdown Elements Survive in Each Route?

Here's how one test post fares across the three routes, based on each route's documentation and plugin pages. The post contains a heading, bold text, a link, a bullet list, a pipe table, a fenced code block with a language hint, a blockquote, and a task list.

Element	Custom HTML block	Jetpack Markdown block	Markdown plugin
Headings, bold, links, lists	Yes	Yes	Yes
Blockquote	Yes	Yes	Yes
Pipe table	Yes, as an HTML table	Test on the front end	Yes (Markup Markdown, Ultimate Markdown)
Fenced code with language	Yes, as pre and code tags	Renders, but highlighting depends on your theme	Yes; some plugins add highlighting
Task list checkboxes	Yes, as disabled inputs	Not documented	Markup Markdown lists it
Footnotes	Yes, as anchor links	Save and check the front end	Plugin dependent

For WordPress Markdown fidelity, the Custom HTML route wins because you inspect the HTML before it goes in. Markdown tables are the first thing to break in the Jetpack block, and fenced code blocks are the second, since the block never adds a highlighting library.

Try the Markdown WordPress Workflow in the Editor

This is the test post. Edit it, then hit convert to get the HTML you'd paste into a Custom HTML block.

Is Markdown Better Than HTML?

For writing, yes. A Markdown draft is shorter, readable in any text editor, and easy to version in Git. For publishing on WordPress, HTML is what the site stores, so Markdown is a drafting format that gets converted at some point. The Markdown vs HTML comparison goes through the trade-offs in detail.

The disadvantages of Markdown are real, though. There's no standard way to set a CSS class, align an image, or build a layout with columns. Every WordPress route above hands those jobs back to the block editor or to raw HTML. If your posts are mostly text with the occasional table or code sample, Markdown saves time. If they're image-heavy landing pages, write them in blocks.

One more caveat: the block editor's paste handler can turn simple pasted Markdown (a # heading, a - list, **bold**) into blocks on its own. In our experience it's inconsistent with tables and fenced code, so treat it as a convenience rather than a fourth route.

WordPress Markdown FAQ

The right WordPress markdown route depends on what you're willing to install. No plugin means convert and paste into a Custom HTML block; Jetpack means the Markdown block with CommonMark limits; a dedicated plugin means a different storage format. Whichever you pick, draft in the editor first, check the preview, and convert once the post is final.