Word’s image anchor system is one of those features that almost nobody understands properly until they’ve been burned by it. Microsoft’s documentation circles around the concept without ever quite explaining it. The forum advice ranges from incomplete to actively wrong. And the visible cues Word gives you — that small anchor icon in the margin — are off by default in a fresh install.

This is the comprehensive reference. Read it once, internalise the model, and you’ll never lose another half-hour to images doing things you can’t explain.

The mental model that fixes everything

Every floating image in Word has two properties that work together: a position and an anchor. They are not the same thing, and the relationship between them is the source of essentially every image-positioning frustration users have.

  • Position is where the image appears on the page. Top-left corner. Three centimetres from the left margin. Centred horizontally. Whatever you’ve set.
  • Anchor is the paragraph the image is attached to. The anchor is a logical link from the image to a specific paragraph in your text. It controls when (and whether) the image moves.

Crucially, the anchor doesn’t decide where the image is. It decides what happens to the image when the document changes. Think of the anchor as a tether and the position as a current location. The image is here. The tether reaches over there. If the tether’s end (the anchored paragraph) moves, the image may or may not follow — depending on settings we’ll get to.

If you only take one thing from this article, take this: the anchor is about the future, not the present.

See the anchor first

Before any of this makes sense, you need to be able to see the anchors. Word hides them by default and this is the single most important display setting it ships with off.

File → Options → Display → Always show these formatting marks on the screen → Object anchors (check the box).

Now, when you click a floating image, you’ll see a small anchor symbol appear in the left margin next to one of your paragraphs. That paragraph is the anchor paragraph. Move the image around manually and watch the anchor — depending on your settings, it may stay where it is or it may jump to whichever paragraph is nearest the image’s new position.

Until you can see anchors, you’re flying blind. Turn them on.

The four states a floating image can be in

A floating image is one whose wrap style is anything other than In Line with Text. Inline images don’t have anchors in the meaningful sense — they live in the text flow as if they were giant characters, and they move when text around them moves because that’s what characters do.

For floating images, there are four meaningfully different states controlled by two settings: Move object with text and Lock anchor. Both live under Right-click image → More Layout Options → Position tab → Options section.

State 1: Move with text ON, Lock anchor OFF (default)

The image’s vertical position is paragraph-relative. The anchor can be reassigned freely when you drag the image. When the anchored paragraph moves (because of edits elsewhere), the image moves with it.

This is what most users mean when they complain about images “jumping” — they’re seeing this default behaviour and they didn’t ask for it.

When this state is correct: long documents where each image is conceptually attached to a specific block of body text, and you want the image to stay with that block wherever it ends up. Academic papers, technical manuals, long reports.

State 2: Move with text OFF, Lock anchor OFF

The image’s position is page-relative. The anchor can still be reassigned when you drag the image, but edits to text don’t move the image. You can edit freely above the anchor paragraph; the image stays where you put it.

When this state is correct: most one-page and short documents where you’ve placed an image deliberately and you want it to stay there regardless of body-text edits.

State 3: Move with text OFF, Lock anchor ON

Position is page-relative and the anchor is locked to its current paragraph. The image won’t move when you edit text. Crucially, the anchor also won’t reassign itself if you drag the image — it stays attached to its original paragraph.

When this state is correct: templates, formal documents, anything where you want positional behaviour to be deterministic and survive future editing by people who don’t understand any of this.

State 4: Move with text ON, Lock anchor ON

The anchor is locked to its paragraph, but the image moves with that paragraph. So edits that move the paragraph also move the image. This is a slightly unusual combination — useful when you want a specific image to travel with a specific block of text, no matter how that text gets edited, and you want to prevent anyone from accidentally reassigning the anchor by dragging the image.

When this state is correct: documents where image-to-text association is critical (caption-image pairs, instructional steps tied to figures) and the document will be heavily edited.

How positioning actually works

There are two ways to specify where a floating image goes, and they behave differently:

Absolute position. “5 cm from the page” or “2 cm from the left margin.” Word puts the image at that coordinate. With Move-with-text OFF, the image stays there.

Alignment-based position. “Centred relative to the page” or “Right-aligned to the column.” Word recomputes the position as the page geometry changes. If the page size changes, or you switch to landscape, the image’s position updates to maintain the alignment.

For predictable behaviour, specify positions explicitly using “Absolute position” relative to “Page”. This is the most stable configuration and survives the most kinds of document editing without surprises.

Alignment-based positioning is useful but it interacts with anchor changes in ways that catch people out. If your image is “centred relative to column” and you delete a column break, the column it was centred to no longer exists, and the image will reposition.

The Allow Overlap setting

A lesser-known setting that matters when you have multiple images on a page.

Position tab → Options → Allow overlap (default: ON for new images created in Word 2010 and later).

With Allow Overlap ON, two floating images can occupy overlapping page regions. Their relative stacking is determined by their order in the document. This is what you usually want.

With Allow Overlap OFF, Word actively prevents floating images from overlapping. If you place a second image where it would overlap a first, Word will push it elsewhere. This is the source of a particularly maddening behaviour pattern: you place an image, it appears somewhere you didn’t put it, and you can’t figure out why. The answer is that a different image (often a transparent shape, a text box, or an image you don’t see clearly) is in the position you tried to place at, and Word relocated your image to avoid the overlap.

If you’re seeing inexplicable position changes when you place images on a page that already has images, check Allow Overlap on all of them.

Layout In Table Cell

If your image is inside a table cell — even a single-cell table being used purely for layout — there’s an extra setting that controls how it relates to the cell:

Position tab → Options → Layout in table cell (default: ON).

With this on, the image’s positioning is relative to the table cell rather than the page. With it off, the image positions relative to the page even though it’s nested inside a cell.

Most users want this on for images placed inside cells, but if you’re trying to place an image at a fixed page position and you’ve accidentally got it nested in a single-cell layout table, turning this off makes the page-relative positioning work as expected.

Anchor reassignment behaviour

When you drag an image around the page, Word continuously reconsiders which paragraph to anchor it to. By default, it picks whichever paragraph is closest to the current position of the image. This is why anchors appear to “follow” the image as you move it.

With Lock Anchor on, the anchor doesn’t reassign. The image moves freely; the anchor stays on its original paragraph. This decouples positional dragging from anchor location entirely.

If you’ve ever dragged an image to a new position and then wondered why deleting a paragraph in a completely different part of the document moved the image, this is your answer: the anchor reassigned when you dragged, and you didn’t notice.

The gotchas that catch everyone

A short list of behaviour that nobody warns you about:

Deleting an anchored paragraph deletes the image. If you delete the paragraph that an image’s anchor is attached to, Word deletes the image along with it. This is the single most disastrous gotcha in the system. The fix is to either move the anchor to a different paragraph before deleting, or to lock the anchor (which protects against this).

Anchors at the start of a section. If an image is anchored to the very first paragraph in a section, and you delete the section break before it, the anchor moves into the previous section. Image positioning often jumps unexpectedly as a result.

Header/footer anchors. Floating images in headers and footers behave subtly differently. The anchor system still exists but the positioning model treats them as page-area-relative. If you’ve copied a body-area floating image into a header without noticing, its behaviour will surprise you.

Saving in older formats. Saving a .docx as .doc strips Lock Anchor information. The image is still there, the position is still there, but the lock is gone. If you’re collaborating with users on legacy Word versions, your locked anchors are not protected.

Word for the web. The web version of Word has historically had patchy support for Lock Anchor and has been known to silently strip the setting on save. We covered this in Word: how to stop images jumping pages when you edit.

Track Changes. With Track Changes on, image insertions and deletions are tracked, but anchor reassignments often aren’t visible in the track-changes pane. An image can appear to behave differently in the accepted-changes view than in the all-markup view, because the anchor in one is at a different paragraph than in the other.

The diagnostic flow when things go wrong

If you’ve inherited a document with images that won’t behave and you need to make sense of it:

  1. Turn on anchor visibility if it isn’t already on (File → Options → Display → Object anchors).
  2. Click each problematic image and note where its anchor currently is. The relationship between image position and anchor position is usually the first clue.
  3. Open More Layout Options on the misbehaving image and check the Position tab. Note the current Move with text and Lock anchor settings, and the current positioning mode (Absolute vs Alignment).
  4. Apply the configuration you actually want — usually Move with text OFF, Lock anchor ON, Absolute position relative to Page.
  5. Save and test by editing unrelated parts of the document. Does the image stay put? If yes, you’ve fixed it. If no, you’ve probably got a setting one level deeper — usually Layout in table cell, or an Allow Overlap collision with another image.

What Microsoft should fix

This is a long-standing complaint and worth saying plainly. The defaults are wrong for most use cases. The most important settings are buried two dialogs deep. The visible cue (the anchor icon) is off by default. The single most catastrophic behaviour in the system (anchor deletion taking the image with it) has no warning.

Word has had decades to surface these settings, change the defaults, or at least default-on anchor visibility. None of it has happened. The result is that millions of hours of user time are lost to image positioning problems that have a perfectly good solution Word doesn’t bother to make discoverable.

Until that changes, the answer is to learn the model once, set images deliberately, and stop accepting Word’s defaults for serious documents.

For the practical configuration that stops the most common jumping behaviour, see Word: how to stop images jumping pages when you edit — the focused fix. For the related rendering problem where images go invisible rather than misplaced, see empty placeholder boxes in Word. And if your images are surviving the editing process but degrading on save, see Word image quality drops after save.