I have a use case where content editors have a requirement to specify the height and the width of an image in the image properties. Sticking to styles is not possible because $reasons.

The CKEditor demo has this:

CKEditor demo with dimensions option

But the Drupal 8 image properties looks rather sparse in comparison.

Drupal 8 image properties

I've looked all over for this for hours, and this is the first time I've had to write my own Drupal Answers question!

Does anyone know how we can expose the option to set width and height in CKEditor?

I'm aware of IMCE - but expected behaviour of the module in Drupal 8 is to use IMCE for file upload only - once an image is placed, image properties is handled by CKEditor.

There is a YouTube video where someone has managed to configure CKEditor to use IMCE's image properties: https://www.youtube.com/watch?v=2eTfQ7Y4i5I but there's no instructions on how this was achieved, and a comment-or asked but has been hanging for a year.

I'm totally new to Drupal 8, would like to know how to do this! And then I'll figure out how to make sure the change isn't reverted next time core is patched :)

  • 1
    I find that the best way to handle this is to use Media and control the sizes through View Modes (because they tie to Image Styles). Raw image/height attribute is unpredictable IMO for the average editor, where a select box is easier for them. Look into Media, Media Entity, Media Browser.
    – Kevin
    May 17, 2018 at 12:56
  • Maybe it's a little too late and not ideal, but you can try drag the corner of the image: i.imgur.com/kotFKrW.png Dec 11, 2020 at 18:59

2 Answers 2


Depending on how far you are in your project consider using Paragraphs instead, to have your content built modularly. Inline images are bad practice IMHO. They are difficult to preprocess and difficult to apply responsive image styles.

With Paragraphs (or in general with a fieldable approach instead like Kevin pointed out in the comments) you'd provide certain paragraph types, for example one for pure text and one for an image. Editor then places an image paragraph, followed by a text paragraph and the text simply floates around the image. You can have responsive image styles for the image, you can build the image field according your logic to provide certain crop types etc.

I know this is not the answer you might look for, but honestly for the sake of maintainability think about it if putting everything into the body field will still work in the long run. In my experience this can lead to a very big mess. Hard to disassemble, hard to migrate, hard to maintain.

  • 1
    Sure, this is usually a battle with designers though depending on how they do this. Media + Media Browser + View Modes (media) and a handful of image styles is the next best substitute. I am also a huge proponent of fields being on the media type, instead of fields being on the paragraph with a media type - this solidifies the object model for media items.
    – Kevin
    May 17, 2018 at 12:56
  • 1
    Thanks for responding - you're absolutely right and it has been explained. For this project I think paragraphs is even overkill! Images really are few and far between with most pages being text, and IMO being able to chose left/right/centre align should be enough. But it's something they had in D7 so there's an expectation that it should be here too... To be honest, if it wasn't something so rare on their site I'd be really fighting for paragraphs too, but I can trust them here. May 17, 2018 at 13:11

The paragraphs approach mentioned above could definitely work depending on your use case - another pattern is using Drupal Media entities and Media Library or entity browser to embed images. This also allows you to use things like the Focal Point module. (overview here: Core Media Overview)

With this design pattern you can utilize image styles which allows users to pick sizes and cropping rules you've defined (image styles are config). It also gives you (often significant) performance improvements because derivative optimized images are created, meaning a big source file isn't served in the browser. Let's walk through how this might look "in the wild":

Someone is editing content in a blog post and they want to use an image within their text. They would click the entity embed button (configured by you) and can either browse other images already in the site, or upload a new one. When a user picks the "medium image" style after choosing/uploading their image, they receive a resized 150px max width image - based on your configuration of the "medium image" image style. Instead they realize they want the image to be square, they change the image style to "square crop (150)" instead. You have configured this to scale and crop the image, respecting the focal point the user has chosen.

They can see this previewed in the WYSIWYG and then can also use this image elsewhere as the blog node's teaser in the media reference field there.

When they load the page, it loads quickly because the images have been generated at the specified size using the media kit, even though they uploaded 3MB images to use. (actual file: my_image_sq_crop_150.png)

This type of design pattern is a generally accepted best practice in D8 that does require a bit of upfront configuration to get in place. It can also work very well along side the more constrained paragraphs approach which allows you to treat the content there as a "content and image component". I hope that helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.