If you inherited a Drupal 8 site, inline responsive images are less about visual polish and more about editorial control. The problem is familiar: authors drop large images into body copy, set arbitrary widths in the editor, and the page looks acceptable on desktop but messy on mobile. The original note here was directionally right that the Inline Responsive Images approach works on a mostly standard Drupal build. What it needed was the practical context: how to configure it cleanly, where teams get stuck, and when not to spend any more time on a Drupal 8-only solution.
Start with the business reality
Drupal 8 reached end of life on November 17, 2021. So if your site is still on Drupal 8, this should be treated as a containment and migration decision, not a fresh platform choice. Inline responsive images can still help a legacy team reduce content breakage and support load, but the configuration should stay simple enough to move forward into a supported version later.
What inline responsive images should solve
For most teams, the goal is not to give editors more image controls. It is the opposite. You want editors to choose from a small set of approved presentation options while Drupal handles the right file size for the viewport. Drupal's responsive image system maps image styles to breakpoints, and the Inline Responsive Images module extends that logic into the text editor so users can select a responsive style instead of typing dimensions by hand.
That is still the right operating model for content-heavy organisations: fewer one-off image decisions, better consistency across articles, and less QA time spent fixing stretched or oversized images after publication.
A practical legacy setup
If you need this working on an inherited Drupal 8 build, keep the setup boring and disciplined:
- Create only a few image styles. Start with clear editorial cases such as
inline_small,inline_medium, and maybe one wider pull-out option. Too many choices slow authors down and create inconsistency. - Define breakpoints in the theme, not just in CSS. Drupal uses
*.breakpoints.ymlfor breakpoints that responsive image mappings can consume. There is no Drupal 8 UI for editing them. A minimal example looks like this:
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 adding or changing breakpoints, rebuild caches. If you use Drush, drush cr is the usual quick route.
- Create the responsive image style. In
/admin/config/media/responsive-image-style, map those breakpoints to image styles so small screens get smaller assets and larger screens can use a larger derivative when needed. - Configure the text format carefully. The contributed module's own guidance is important here: enable either the Display responsive images filter or the Display image styles filter on a given text format, not both. Also test filter order if you use Restrict images to this site or Track images uploaded via a Text Editor, because the module expects its filter to run after them.
- Expose only the styles editors should actually use. A dropdown with three sensible choices is governance. A dropdown with twelve choices is a training problem.
Where teams usually go wrong
- They solve the wrong problem by letting editors set width and height manually. That creates local fixes, not a reusable content system.
- They define CSS breakpoints but never register them in
.breakpoints.yml, so the responsive image tools have nothing reliable to map against. - They create too many image styles. Editorial freedom sounds helpful, but it usually turns into inconsistent article layouts.
- They forget that inline images are still content assets. Alt text, captions, and a basic image naming convention matter if more than one team touches the site.
If you are already upgrading, use the modern path
The important correction is this: current maintained releases of Inline Responsive Images target newer Drupal versions, not Drupal 8. If you are already in upgrade work, that is where you should invest:
composer require 'drupal/inline_responsive_images:^3.0'
composer require 'drupal/inline_responsive_images:^4.0'
On supported Drupal versions, CKEditor 5 and Media Library are the cleaner long-term direction for editorial image workflows. That does not mean you must rebuild everything immediately, but it does mean new effort should move toward supported core patterns rather than deeper Drupal 8 customisation.
The practical recommendation
If the site is staying on Drupal 8 for a short period, use inline responsive images to reduce editorial mistakes and keep article layouts stable on smaller screens. Keep the style set tight, define breakpoints properly, and document the author workflow in one page for your team. If the site has a budget for improvement, pair this cleanup with an upgrade plan so you are not solving the same publishing problem twice.
If you need help stabilising a legacy Drupal content workflow, reducing editor friction, or mapping the least-disruptive upgrade path, that is the kind of Drupal cleanup and delivery planning I help teams with.
Need help with this kind of work?
Need a pragmatic plan for a legacy Drupal site, content workflow cleanup, or a low-risk upgrade path? Let's talk. Get in touch with Greg.