Drupal 8 Inline Responsive Images: A Practical Legacy Setup

By Greg Nowak. Last updated 2026-07-07.

If you inherited a Drupal 8 site, inline responsive images are not mainly a design polish task. They are an operations problem. Editors need a predictable way to place images inside body copy without guessing pixel widths, uploading oversized files, or breaking mobile layouts after every content update.

The right setup gives editors fewer choices, not more. Drupal should handle image derivatives and responsive markup; authors should choose from a small set of approved presentation options. For a legacy site, the bigger question is how much effort belongs in stabilising the current workflow and how much should move into the upgrade plan.

Start with the support reality

Drupal 8 reached end of life on November 17, 2021. That means Drupal 8-only core and contributed project releases are outside normal security support. So treat this work as containment: reduce publishing mistakes, keep pages usable, and avoid customising yourself further away from a supported Drupal 10 or Drupal 11 path.

Inline responsive images can still be worth fixing on a live Drupal 8 site when editors are actively publishing and image problems are creating QA or support load. It is rarely worth turning into a large standalone project. Keep the configuration simple enough to document, test, and migrate later.

What the setup should accomplish

Drupal's responsive image system maps image styles to breakpoints so smaller screens can receive smaller image files, while larger screens can receive more suitable derivatives. For inline body images, the contributed Inline Responsive Images module adds the missing editorial bridge: it lets users select a responsive image style or image style from the editor instead of typing dimensions by hand.

That distinction matters. Manual dimensions create one-off fixes. Responsive image styles create a reusable content rule. For business owners and operations leads, the value is less cleanup after publication, better consistency across articles, and a clearer path for agency teams who later have to upgrade or rebuild the theme.

Situation	Best move	Why it works
Drupal 8 site is still publishing weekly	Stabilise inline responsive images with a small approved style set	Reduces editor mistakes while the site remains live
Upgrade to Drupal 10 or 11 is already funded	Prioritise CKEditor 5, Media Library, and supported module versions	Avoids spending too much on Drupal 8-only workflow debt
Editors use many custom widths and alignments	Replace free-form sizing with named styles and documented examples	Makes layout behaviour easier to train and test
Image issues are mostly on listing pages or content types	Fix field display and view modes before inline images	Structured image fields are easier to govern than body HTML

A practical decision matrix for deciding how far to take inline responsive image work on a legacy Drupal site.

A disciplined legacy configuration

Start with image styles that match real editorial use cases. Three choices are often enough: inline_small, inline_medium, and one wider option for articles that genuinely need it. Avoid names that describe implementation details only. Editors understand “small inline image” better than “480w 2x crop”.

Next, make sure Drupal knows about the breakpoints your theme uses. CSS breakpoints alone are not enough when Drupal's Responsive Image module needs to map styles to viewport rules. Define them in your theme's *.breakpoints.yml file, with weights ordered from smaller to larger breakpoints. A compact example:

mytheme.editor_images.mobile:
  label: mobile
  mediaQuery: ''
  weight: 0
  multipliers:
    - 1x
  group: mytheme.editor_images

mytheme.editor_images.desktop:
  label: desktop
  mediaQuery: '(min-width: 64em)'
  weight: 1
  multipliers:
    - 1x
    - 2x
  group: mytheme.editor_images

After changing breakpoints, rebuild caches. On many projects that is simply:

drush cr

Then create or adjust the responsive image style at /admin/config/media/responsive-image-style. Map each breakpoint to the image style Drupal should use at that size. Keep the mapping boring: small derivative for mobile, sensible larger derivative for desktop, and high-density variants only where they are actually useful.

Configure the editor with restraint

The Inline Responsive Images module documentation is clear on one easy-to-miss point: enable either the Display responsive images filter or the Display image styles filter for a text format, not both. If the text format also uses filters such as Restrict images to this site or Track images uploaded via a Text Editor, test the filter order so the inline responsive image filter runs after the filters it depends on.

Expose only the styles editors should use. A short dropdown is governance. A long dropdown becomes a training problem, especially when multiple departments or agency teams publish into the same site.

Know when to use the modern path

If you are already planning an upgrade, do not over-invest in Drupal 8-specific editor behaviour. Current Inline Responsive Images 4.0 releases support Drupal 10.3 and Drupal 11 with CKEditor 5. The older 3.0 line is deprecated and targets older supported combinations. Use Composer deliberately:

composer require 'drupal/inline_responsive_images:^4.0'

For Drupal 10 and newer, CKEditor 5 and Media Library are the more future-facing editorial pattern. Media embedding is configured through the text format, the Media Library button, and the Embed media filter. That does not automatically replace every inline image use case, but it is usually the better direction for reusable assets, alt text workflows, captions, and view modes.

What I would recommend

If your Drupal 8 site must keep publishing for a few more months, stabilise inline responsive images now: define breakpoints properly, limit the style list, document the author workflow, and test a few real articles on mobile. If the site has budget for improvement, pair that cleanup with an upgrade plan so the same content problem is not solved twice.

Need a pragmatic plan for a legacy Drupal content workflow, image handling, or a low-risk upgrade path? Get in touch with Greg and make the next step clearer before the work gets bigger.