Jorge Tutor’s CKEditor5 Markdown Module Gives Drupal Editors a Controlled Paste Path

Editors who move Markdown drafts into Drupal now have a controlled option inside CKEditor5. Jorge Tutor, chief information officer and program director at Metadrop and maintainer of the CKEditor5 Markdown module, told The DropTimes that the contrib project grew from a production need: convert Markdown to HTML deliberately, not through hidden clipboard detection.

The module is aimed at editorial teams that draft outside Drupal, including in notes apps, code editors, documentation systems, and AI-assisted writing tools. Instead of relying on CKEditor5’s experimental Paste Markdown feature, CKEditor5 Markdown adds a toolbar button that opens a dialog, lets editors review Markdown, and inserts the converted HTML at the cursor. The result is a visible editorial step before Drupal’s configured text format accepts or rejects the generated HTML.

In the LinkedIn post that prompted the follow-up, Jorge described a related open-source Markdown-to-HTML converter for moving Markdown into HTML-only publishing surfaces. The Drupal module sits in the same problem space, but shifts the handoff inside CKEditor5 and Drupal’s text-format system. In both cases, the underlying friction is the same: Markdown works well for drafting, while many publishing workflows still require HTML.

Drupal.org lists the project as created on 28 May 2026 and updated on 12 June 2026. The 1.0.0 release, published on 14 June 2026, works with Drupal ^10.3 || ^11 and is covered by Drupal’s security advisory policy. Site builders still need the core ckeditor5 module enabled before adding the toolbar button to a text format.

In use, the button opens a dialog rather than immediately processing the clipboard. The content is parsed with the marked JavaScript library, version ^9.0.0, using GitHub-Flavored Markdown support. The compiled asset bundles the library at js/build/markdownPaste.js through Webpack, so the module does not require a separate frontend build step for normal installation.

Jorge said in written responses shared with The DropTimes that the module came from a reliability gap in CKEditor5’s built-in Paste Markdown support. CKEditor5 includes a feature that detects Markdown in the clipboard and converts it on paste, but the feature is still marked experimental in CKEditor’s own documentation. For a newspaper-style editorial workflow, he said, that status was not enough because editors need a conversion path that behaves consistently during production work.

He also pointed to a long-running CKEditor5 issue around Markdown paste support and said the module avoids waiting for CKEditor5’s roadmap to settle that problem. The decision to use marked.js was not presented as a new parsing invention, but as a practical engineering choice. Jorge described it as a widely adopted, actively maintained, and battle-tested library that gives the Drupal module a stable Markdown-to-HTML conversion engine of its own.

That choice also affects how the module is maintained. By bundling the parser directly into the CKEditor5 plugin, the conversion layer is part of the module’s compiled asset. Editors and site builders do not need to manage a separate browser-side dependency during normal use, and the module does not depend on CKEditor5’s experimental clipboard detection to decide whether a pasted block looks enough like Markdown to transform.

Jorge said in written responses shared with The DropTimes that the dialogue workflow was chosen to give editors a controlled moment before conversion, especially when content comes from tools such as Obsidian, AI chat outputs, or other drafting environments.

“The dialog gives editors one last chance to review and clean up their Markdown before it lands in the editor.”

The distinction is not that CKEditor5 lacks Markdown-related tooling. CKEditor5 documents a Paste Markdown feature that converts Markdown-formatted content into rich text on paste, and the related CKEditor 5 Plugin Pack documentation describes an automatic Paste Markdown plugin for Drupal text formats. Jorge’s module uses a different interaction model: the editor explicitly decides when conversion happens.

That choice addresses a practical editorial problem. Clipboard-based conversion can be difficult to diagnose when multiple paste-related plugins are active, including Paste from Office, Paste from Google Docs, and Autoformatting. A paste event may pass through several assumptions before the editor sees the final result, especially on sites with a customised CKEditor5 setup. In that environment, conversion can depend not only on the Markdown source, but also on which plugins are enabled and how they interact.

Jorge said automatic clipboard detection is opaque for editors because the conversion happens first and the review happens afterwards. If the detected Markdown is incomplete, or if another paste plugin changes the content before Markdown conversion runs, the editor may only discover the problem after the content is already inside CKEditor5. The dialog reverses that order. Editors can paste the Markdown into a textarea, inspect it, correct obvious formatting problems, and only then insert the generated HTML.

Drupal already has Markdown options with different storage and rendering assumptions. CKEditor 5 Markdown Editor focuses on Markdown output in CKEditor5, while Markdown Easy uses a text filter to convert Markdown to HTML at render time. CKEditor5 Markdown instead converts once and inserts HTML into CKEditor5’s model, leaving the saved content in the same format as other editor-produced HTML.

Jorge said this difference is central to the module’s purpose. Markdown output or render-time Markdown filters can work well when a site is built around Markdown as the source format. They are less straightforward when editors combine Markdown with HTML, inline CKEditor5 editing, media embeds, layout-oriented editor features, or existing text-format rules. In those cases, storing raw Markdown and converting it later can create filter-chain dependencies and unexpected rendering differences.

The module’s model is narrower. It treats Markdown as an authoring input rather than a permanent content format. Once the editor confirms the dialog, the Markdown becomes regular CKEditor5 content. Jorge described this as a “convert once, store HTML” approach, intended to avoid mixed-format problems while still giving editors the speed and portability of Markdown during drafting.

Installation follows the usual contrib pattern: composer require drupal/ckeditor5_markdown, followed by enabling the module through the Drupal admin interface or with drush en ckeditor5_markdown. Site builders then edit the relevant CKEditor5 text format under Administration > Configuration > Content authoring > Text formats and editors, and drag the Paste Markdown button into the active toolbar. The release page also provides the version-constrained Composer command composer require 'drupal/ckeditor5_markdown:^1.0'.

That configuration step is not only about making a button visible. In Drupal, text formats define what editors are allowed to create and what HTML is accepted. A team may enable the module on one format used by trusted editors, but leave it unavailable on a more restricted format used by occasional contributors. That makes the module part of Drupal’s existing editorial permission model rather than a separate content pipeline.

The main production risk sits in CKEditor5 configuration, not in the Markdown parser. If Markdown produces <table>, <h1>, images, links, or fenced code blocks, CKEditor5 accepts only what the text format’s enabled plugins and allowed HTML settings support. A Markdown heading such as # Heading 1 will not survive as <h1> unless the Heading plugin is enabled and <h1> is configured as an allowed heading level.

Jorge said the module uses marked.js with GitHub-Flavored Markdown enabled, so it can produce a broad range of HTML. That includes headings from <h1> through <h6>, paragraphs, fenced code blocks with language classes, links, images, ordered and unordered lists, blockquotes, tables, strikethrough, and raw passthrough HTML. The parser can generate those structures, but CKEditor5 still decides what is allowed into the editor model.

He explained that the generated HTML is inserted through CKEditor5’s data pipeline, moving from data.processor.toView() to data.toModel() and then model.insertContent(). At that point, CKEditor5 applies the rules set by the active text format and enabled plugins. A table may be converted from Markdown correctly, but it can still disappear if the Table plugin is not active. The same principle applies to code blocks, headings, images, links, and other elements.

Jorge said the conversion can produce rich HTML, but the final result is governed by CKEditor5’s own data pipeline and active plugins. That makes staging tests important before the workflow reaches a production newsroom or content team.

“The module converts faithfully; CKEditor5 then filters to what the editor is actually configured to support.”

For production editorial sites, the main review point is the text format where the button is enabled. Teams should test representative Markdown samples in staging, especially tables, code blocks, headings, images, links, blockquotes, and raw HTML. If a required CKEditor5 plugin is missing, content can be dropped without a visible error, turning a conversion feature into a training and configuration problem.

Jorge said site builders should start by reviewing the Markdown features their editors actually use. Tables require the Table plugin. Fenced code may require Code Block or Source Code support, depending on the site’s policy. Headings require the Heading plugin and the intended heading levels. Links require link support, while images depend on the editor configuration and the site’s media handling rules.

He also recommended enabling the module first in a staging environment and testing realistic content rather than short artificial samples. A useful test set would include a full article draft with headings, lists, links, blockquotes, tables, inline code, fenced code, and any raw HTML the team expects to paste. The goal is not only to confirm that conversion works, but to confirm that the site’s CKEditor5 configuration preserves the structures the editorial team expects to publish.

The release also reflects a wider authoring pattern in Drupal teams: drafting often happens outside the CMS, while publishing still depends on CKEditor5 and Drupal’s text-format governance. Jorge described the module as part of a daily workflow where content may begin in Markdown before being edited and published in Drupal. The community value is not tied to one drafting tool; it is the controlled handoff from structured plain text to configured HTML.

That handoff has become more visible as content teams use different drafting surfaces for different stages of work. Developers may draft documentation in code editors. Editors may prepare outlines in note-taking applications. Writers may move AI-assisted drafts into a human editing process before publication. In each case, Markdown often functions as a portable working format, while Drupal remains the publishing system that must apply permissions, text-format rules, editorial review, and final HTML output.

Jorge framed the module as a practical bridge for that workflow rather than a broad replacement for existing Markdown approaches. Its purpose is not to turn every Drupal site into a Markdown-first publishing system. It gives teams that already publish through CKEditor5 a cleaner way to bring Markdown into the editor without asking them to store Markdown permanently or depend on experimental paste detection.

“It’s solving the specific friction of bringing Markdown content into a WYSIWYG workflow without losing structure.”

CKEditor5 Markdown is a focused module rather than a replacement for broader Markdown workflows in Drupal. Its value is clearest where editorial teams want Markdown as an authoring convenience, but not as the stored or rendered content format. For those teams, the module offers a small, explicit step between drafting and publishing: review the Markdown, convert it once, and let CKEditor5 enforce the site’s configured HTML rules.