Copy and Paste Images from the Clipboard in Drupal

By Greg Nowak. Last updated 2026-06-19.

If your editors regularly paste screenshots from Slack, a browser, or a desktop snipping tool into Drupal, this can be a genuine time-saver. It can also become a low-grade support problem when the setup is only half right: images appear in the editor, disappear on save, land in the wrong place, or bypass any useful asset governance. The original note behind this page pointed to older Drupal 8-era add-ons. As of June 19, 2026, that advice is outdated. On modern Drupal, clipboard image handling is mainly a CKEditor 5 and text-format setup question, plus a decision about when direct paste is fine and when Media Library should be the rule.

The short answer in 2026

For a current Drupal site, start with core, not legacy contrib. The Drupal.org page for Image from Word now says the module is no longer required for Drupal 9.3 and later because the relevant behavior works from core with CKEditor 5. The older CKEditor Upload Image project sits in the CKEditor 4 ecosystem and currently has no supported stable releases. That is the practical dividing line: if your site is on Drupal 10 or 11, this is usually a configuration and workflow task, not a hunt for yet another upload module.

Just as important, do not solve clipboard pasting by allowing base64 image blobs to live inside stored HTML. CKEditor's own documentation warns that this creates heavier content, slower transfers, and no browser caching. For a real business site, you want uploaded files or managed media items, not giant data URIs buried in the body field.

Editorial need	Best fit	Why
Editors paste one-off screenshots	CKEditor 5 clipboard upload in core	Fastest route for operational content when reuse and asset governance are not the main concern.
Shared assets used across many pages	Media Library	Better for reuse, permissions, alt text, and consistent display rules.
Site still depends on CKEditor 4-era contrib	Upgrade plan first	Legacy upload modules are not the right foundation for a current Drupal content workflow.
Custom or decoupled editorial UI	Supported CKEditor 5 upload adapter plus server endpoint	Default Drupal editor behavior does not automatically transfer to custom integrations.

A simple decision rule: use direct paste for fast screenshots, and Media Library when the image needs reuse, governance, or a consistent presentation model.

Recommended setup for most Drupal teams

Configure the text format editors actually use. Go to /admin/config/content/formats, open the format tied to day-to-day editing, often Basic HTML, and confirm it uses CKEditor 5. Test with a normal editor account, not only a site builder login.
Allow direct paste for quick, one-off images. This is the right fit for support screenshots, annotated browser captures, and internal knowledge-base visuals that do not need long-term reuse. If an image appears while editing but vanishes after save, the first things to inspect are the text format rules and upload permissions.
Use Media Library for reusable or governed assets. Drupal's current Media Library guidance for CKEditor 5 recommends adding the Media Library button to the toolbar and enabling the Embed media filter. That is the better route for logos, campaign images, product photography, and anything that should be reused across pages with consistent handling.
Treat custom editorial interfaces as a separate implementation. If your team edits content through a custom admin screen, a decoupled front end, or a bespoke workflow tool, do not assume Drupal's default editor behavior will carry over. CKEditor 5's supported upload flow expects a server-side upload endpoint and server-side file filtering.

Operational checks that prevent editor frustration

Decide where direct paste is allowed. A simple rule works well: pasted screenshots are fine, brand assets go through Media Library.
Set file-type and size expectations. High-DPI screenshots can be much larger than people expect, and that affects storage, review speed, and page weight.
Be explicit about alt text. If editors paste procedural screenshots, decide whether they must add descriptive alt text immediately or whether the image is decorative in context.
Test more than one source. Clipboard pasting should be checked from operating-system screenshots, Word, Google Docs, and the browser tools your editors actually use.
Think about clean-up. Direct paste is fast, but it can create lots of near-duplicate files unless someone owns retention and reuse policy.

If your team manages Drupal configuration in code, a quick Drush sanity check is still useful:

drush pm:list --status=enabled --type=module | grep -E 'ckeditor5|media|media_library|image'
drush cex -y
drush cr

Where teams usually get stuck

The hard part is rarely the paste action itself. The hard part is deciding how editorial speed, content governance, and front-end consistency should work together. Teams often want the convenience of pasting everything directly into the editor, then later discover they also want central asset reuse, reliable alt text, consistent crops, and fewer duplicates. Those are not the same workflow.

A practical compromise is to support both routes on purpose. Let editors paste quick screenshots when speed matters. Require Media Library for assets with a longer shelf life or a design standard attached to them. That gives operations leads a clear rule, gives agency teams a cleaner implementation brief, and keeps content editors out of the middle of a technical argument they should not need to solve on every page.

If your Drupal team is still relying on CKEditor 4-era advice, disappearing pasted images, or an unclear split between pasted files and managed media, the fix is usually smaller than a rebuild but larger than a one-click module install. It is a short review of text formats, upload handling, and editorial policy. That is exactly the kind of cleanup worth doing once, properly.

Related on GrN.dk

Need help with this kind of work?

Need this standardized across a Drupal team? Greg can help align CKEditor, Media Library, and publishing rules without turning it into a larger rebuild than necessary. Get in touch with Greg.