Test page to demonstrate unexpected alignment of Image blocks.
The page uses the “Pages” template, with Paragraph blocks and Image blocks, with unmodified Twenty Twenty-Four theme (but similar behaviour occurs with any block theme).
The following image block has alignment set to “none”, which means use the normal content width (620px). It aligns the to the left of the content width (as do Paragraph blocks). Text will not wrap around in this case.

The next image block has alignment set to “Align Left”. One might expect the image align to the same width as before, but with text wrapping around it. However, instead it aligns to the left of the container. (Increase the window width of your browser if you don’t see the difference; you won’t see it on a phone or in a window that isn’t wide enough to show a significant white margin both sides.)
Why the difference?

Filler text.
Phasellus at elit gravida, eleifend orci nec, rutrum massa. Phasellus augue nisl, imperdiet id commodo eget, malesuada vel ipsum. Nunc sollicitudin libero leo, et consequat enim blandit vel. Fusce imperdiet malesuada lorem quis volutpat. Donec fringilla a leo non ultrices. Duis pulvinar lacus in venenatis scelerisque. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
The next image block is identical to the previous one, that is: alignment set to “Align Left”, so it should behave in the same way. But there’s a difference. This one is contained within a Group block with default parameters.
This time, the image aligns the same way as paragraph blocks (rather than aligning to the left of the container), and with text wrap.
Why does it make a difference to put the image block inside a group block?

What appears to happen: both paragraph and image blocks by default use the Content width implied by the innermost containing block. In the case of the first two images (and the paragraph blocks with them), the innermost containing block is the Content block in the page template. This has “Inner blocks use content width” turned on, which implies “Nested blocks use content width with options for full and wide widths”.
Image blocks, like paragraph blocks, default to using Content width. But image blocks do something different with Align-left or Align-right. Instead of Content width implied by the innermost containing block, they use “Full width”, that is container width.
With the Twenty Twenty-Four Pages template, the content block inherits full container width from its parent container, and passes that on to the next level. This is because the parent container of the Content block has “Inner blocks use content width” off, which means directly-contained container blocks do not have an Align option, and pass on inherited container width to blocks within the Container block. So an image block at the outermost level in the Pages template has the container width set to the full window width, and uses this with Align-left, Align-right and Full-Width.
However if there is a nested container within the Content block, because the Content block has “Inner blocks use content width” on, the nested block will have an Align option, and the default align is “none”, which confusingly means “set the container width to content width”. Now the image block sees a container width set to content width.
Another twist: this below is similar to the above, that is an image in a group block.

And here is some text to surround the image. As before, the image is set to “Align left” and the text is wrapped round the image. What is not evident unless you edit the page is that the align options for the image are much reduced. The previous image allows “Align” settings of “none”, “wide width” and “full width”. These options aren’t present on this image block. The difference: in this block, the surrounding group block has the parameter “Inner blocks use content width” set to “off”. In the previous image, it’s containing group block has that parameter set “on”.
This behaviour is rather confusing!
There are two main reasons for this confusion. The first is that the “Align” property in the toolbar of many blocks has many different functions:
- Alignment with a content width (e.g. left, right or centre)
- Choice of content width. That is: Normal (described as “None”), Wide or container width (described as “full width”)
- Image stretch (e.g. normal size or stretched to fill the width)
- Text wrap or not around an image
- With the EditorsKit plugin: text justify
- In Container blocks, it is used to set Container width.
With the Image block, setting Align-left (or right) does three things: it sets text wrap on, it sets alignment left or right, and it sets the width to full-width (container width) instead of Content width. You can’t separate these; you can’t have text wrap without using full container width.
The second cause is rather limited documentation on block width, how the widths are set, and how they are inherited through container blocks.
There are three different possible widths for blocks:
- Content width (confusingly called “None” in selection drop-down lists)
- Wide
- Container width (called “Full width” in selection lists)
Most documentation refers only to the first two. These two are ultimately inherited from the template (theme.json on block themes), and can be changed in the Layout section of container blocks, and are inherited by child blocks.
Container width is set initially to the full width of the browser window, but can be changed (to a smaller size) in container blocks with the “Align” property. Slightly unexpectedly, the default in container blocks is to set the container width of a container block to the inherited Content width (rather than the inherited container width). There is an exception: if the parent container of a container block has “Inner blocks use content width” set off, then the container block itself has no Align parameter, and the container width is set to the inherited container width (rather than defaulting to inherited Content width).
Thus the default container width inherited by a block depends not just on the parent container, but on the grandparent container block!
I’ve put more about this at: