This is a working record of Microsoft Office image regressions — bugs that broke image handling in Word, PowerPoint, Excel, Outlook, or related Office surfaces. Each entry is tied to the build that introduced the problem, the KB article or message centre post where Microsoft acknowledged it, and the build that fixed it. Where a regression is still open, that is stated explicitly.

The timeline is updated monthly on the Tuesday after Patch Tuesday. The last full audit was on 27 May 2026.

A few things about how to read this. First, “regression” means a working behaviour broke. Bugs that have always existed in Office are not regressions and are not catalogued here. Second, “image” is interpreted broadly — embedded media, signature images, icons from the Microsoft icon library, transparent PNG handling, SVG rendering, and screenshot-related tooling all count. Third, the dates are the dates Microsoft acknowledged the regression, not necessarily the date the problem started appearing in the wild, which is sometimes earlier.

If you arrived here trying to find out whether your problem is a known regression, scan by app first, then by build number if you have it. The fastest path is usually Ctrl-F on the build number visible in your Office account page.

Active regressions (open or partially fixed)

Classic Outlook: images dropped from Wrap Text Top and Bottom layouts

App: Classic Outlook for Windows Introduced in: Version 2604, Build 19929.20164 and later Acknowledged: 18 May 2026 (Microsoft Support article, last updated 18 May 2026) Status: INVESTIGATING — no fix build committed Symptom: Images embedded in emails, newsletters, or signatures with the Wrap Text “Top and Bottom” layout option do not appear for recipients. Recipients see either a placeholder error or a blank space where the image should have been.

This is the most visible image regression currently affecting business workflows. The defect sits entirely on the classic client; New Outlook for Windows handles the same Wrap Text option without issue on the same release channel. The problem is particularly damaging because, by Microsoft’s own admission, replies and forwards of affected messages may end up permanently missing the image — even after a fix ships to the originating sender’s Outlook, downstream copies in reply chains that have already propagated will not recover the lost image.

Workaround: Avoid the Wrap Text “Top and Bottom” layout. Use “In Line with Text” or one of the other wrap modes until a fix ships.

Why it matters: Newsletter templates, executive signatures, and marketing communications often default to wrap-style layouts. Organisations on Classic Outlook should audit their signature templates and any HTML newsletter templates for this layout option specifically.

Quick Steps grayed out in Classic Outlook (now fixed)

App: Classic Outlook for Windows Acknowledged: 11 May 2026 Status: FIXED — repair landed 8 May 2026 (per Microsoft known-issues hub revisions) Symptom: Quick Steps controls in the ribbon appeared grayed out for affected accounts even when valid Quick Step actions existed.

This one is not strictly an image bug, but it is included because it overlaps with the Wrap Text image regression in the same May 2026 known-issues hub. The Quick Steps grayed-out regression first appeared on 11 May 2026 alongside the image-rendering bug, both surfacing on Classic Outlook and both confined to that client. Quick Steps had been broken for several months before Microsoft pushed the repair on 8 May 2026. The pattern — a feature that takes months to repair in Classic while New Outlook is unaffected — is increasingly characteristic of the current Office release cycle.

January 2026

Classic Outlook: “Encrypt Only” emails unreadable for recipients

App: Classic Outlook for Windows Introduced in: Current Channel Version 2511, Build 19426.20218 Acknowledged: 6 January 2026 (Microsoft support advisory) Status: Workaround issued; fix in flight at acknowledgement. Symptom: Recipients of messages sent with “Encrypt Only” rights protection could not open the message. The encrypted payload appeared as an unreadable attachment rather than rendering as a normal protected email.

The recommended interim path was to either select encryption from the Options ribbon path rather than the toolbar control, or to roll Classic Outlook back to the immediately previous build (19426.20186) using the officec2rclient.exe /update user updatetoversion= syntax. This is an unusual recommendation from Microsoft — explicit version pinning is normally a last resort.

Although the encryption mechanism is not, on the face of it, an image issue, it is included here because rights-protected attachments commonly carry embedded images and the affected workflow displaces inline images into the broken attachment slot. Several organisations reported this regression specifically through inability to receive signed PDF documents containing logos.

Outlook signature inline image loading delays (new Outlook and Outlook for Web)

App: New Outlook for Windows; Outlook for Web Acknowledged: Documented in Microsoft known-issues guidance, January 2026 onwards Status: Ongoing — partial mitigation through async loading improvements Symptom: When composing a new email, signature images load asynchronously. Attempting to send the message before the images finish loading triggers a blocking dialog that prevents transmission. For users on slower connections or in tenants with image-heavy signatures, this creates a perceptible delay between hitting Send and the message actually leaving.

This is not a classic regression — it is a behaviour change driven by New Outlook’s web-architecture foundation, where signature images are fetched from a remote source rather than embedded from local storage as in Classic. The reason it appears on the timeline is that the symptom was new for users migrating from Classic, where signature images were embedded synchronously from local %APPDATA%\Microsoft\Signatures files and never produced a send-blocking dialog.

The pattern of architectural-difference-as-regression is worth flagging because it will recur as more users migrate from Classic to New Outlook.

October 2025 to December 2025

Inline SVG retirement in New Outlook and Outlook for Web

App: New Outlook for Windows; Outlook for Web Announced: Message Centre post MC1130385, updated late September 2025 Status: ROLLED OUT — completion mid-October 2025 (commercial), mid-October 2025 (GCC/DoD/Gallatin) Symptom: Inline SVG images embedded in the HTML body of received emails do not render. Recipients see blank spaces where the SVG would have been.

This is not strictly a regression — it is a deliberate security change. Microsoft retired inline SVG rendering in response to a sharp rise in SVG-based phishing. The Message Centre announcement framed the change in narrow terms: inline SVG rendering would be discontinued in Outlook for the web and in New Outlook for Windows, with affected images replaced by blank slots in the message body. Crucially, SVG attachments remained supported and could still be opened from the attachment well — only the inline rendering path was being closed off.

The change is included on this timeline because for many users the experience is identical to a regression: images that previously rendered now do not. Microsoft’s framing is that fewer than 0.1% of all email images are affected, but the percentage that matters is the share within a specific tenant’s communications — and for organisations whose brand assets rely on SVG, that share can be much higher.

No workaround in the strict sense. The standing recommendation is to substitute PNG or WebP for inline SVG. SVG attachments continue to work and are not affected.

PowerPoint icon library failures (May 2025 carryover)

App: PowerPoint (multiple channels) Originally reported: May 2025 Status: Intermittent through Q3 2025; understood to be infrastructure-side (Microsoft icon servers) Symptom: Insert > Icons returned an empty library or failed to load thumbnails. The most credible explanation circulating at the time — never confirmed by Microsoft — was that the back-end icon library service had been partially or wholly decommissioned, with no client-side update to acknowledge or accommodate the change.

This one is unusual because the failure mode is server-side rather than client-side. The icons in question are pulled at insertion time from a Microsoft-hosted library; when the library is degraded or partially decommissioned, the insertion fails with no useful error message. No specific KB acknowledges this directly — Microsoft’s silence on the matter is itself notable, and the only public explanations have come from third-party admin-blog coverage.

The Office build did not change. The PowerPoint client did not change. The icons stopped loading because something on the Microsoft side changed. That counts as a regression for the purposes of this timeline because it broke a working workflow.

July to September 2025

Office security update KB cycle (image-relevant fixes)

The July through September 2025 Patch Tuesday cycle included multiple Office image-handling fixes shipped alongside security patches. These are listed for cross-reference rather than as user-facing bugs:

  • September 2025 (KB5002779, KB5002780): PowerPoint 2016 and Word 2016 RCE fixes (CVE-2025-54908, CVE-2025-54905). Both vulnerabilities required malicious image-bearing payloads as the trigger surface.
  • August 2025 (KB5002765, KB5002763): PowerPoint 2016 fix for CVE-2025-53761; Word 2016 fixes for CVE-2025-53738, CVE-2025-53736, CVE-2025-53733. CVE-2025-53733 is the Word Preview Pane RCE that could be triggered without user interaction — image-bearing Office documents in the preview pane were the affected vector.
  • August 2025 (Windows component, CVE-2025-50165): Critical Windows Graphics Component RCE rated 9.8 CVSS. The flaw was reachable across the network and stemmed from an uninitialised function pointer hit during JPEG decoding — exploitable through image-bearing Office documents or third-party files. This sits outside Office proper but affects Office image rendering because Office relies on the Windows graphics stack.
  • July 2025 (KB5002746, KB5002745): PowerPoint 2016 fix for CVE-2025-49699 and CVE-2025-49705; Word 2016 fix for CVE-2025-49703.

None of these are user-visible regressions in the classical sense, but they are worth knowing about because they reset the baseline of what is “supposed to work” in image handling. Some sites that were behaving consistently for months changed behaviour subtly after these updates landed.

March to June 2025

Classic Outlook Ctrl+Alt+V (paste special) broken

App: Classic Outlook for Windows Introduced in: Current Channel Version 2503, Build 18623.20156 Acknowledged: April 2025 Status: FIXED — Beta Channel early May 2025; Current Channel Preview early June 2025; full Current Channel late July 2025 Symptom: Ctrl+Alt+V (paste special) did nothing when invoked in Classic Outlook.

This affected image workflows specifically because paste-special is the canonical way to control how an image arrives in a message — as an embedded picture, as a linked picture, as a bitmap, or as a Word picture object. With the shortcut broken, users had to either right-click into the paste options menu or rely on the unmodified Ctrl+V default, which often produced the wrong format for the use case.

The interesting part of this regression is the rollout cadence. From bug acknowledgement to full Current Channel fix was roughly three months. That is not unusual for Classic Outlook regressions; it is faster than some, slower than others. For organisations on the Semi-Annual Channel, the fix arrived later still.

Classic Outlook CPU spike on Semi-Annual Channel (May 2025)

App: Classic Outlook for Windows (Semi-Annual Channel) Introduced in: Version 2406, Build 17726.20126 Acknowledged: April 2025 Status: FIXED — Beta Channel early May 2025; broader rollout late May 2025 Symptom: Sustained high CPU usage during ordinary mail operations including sending. Disabling features or add-ins did not mitigate the spike.

This is not an image bug. It is included here because of the volume of related troubleshooting traffic — many users initially diagnosed the CPU spike as caused by image-heavy signatures, since the spike was most visible during message composition and sending. The actual cause was unrelated to images, but the misdiagnosis pattern was prevalent enough that the regression earns a note here for future timeline searchers.

Historical context (pre-2025)

Outlook 2016 (MSI) — end of support

Date: 14 October 2025 Status: End of support

Outlook 2016 (MSI installation) is no longer receiving updates. End of support for the MSI editions of Outlook 2016 and Outlook 2019 fell on 14 October 2025, after which Microsoft stopped shipping fixes for either version. This matters for the timeline because organisations still running Outlook 2016 (MSI) will retain any image-handling regressions that existed at end-of-support indefinitely.

If you are running Outlook 2016 or 2019 and experiencing image issues, no fix is coming. The path forward is migration to a supported version.

Word image positioning regressions (chronic, not catalogued in detail)

Word’s image anchor and wrap-style behaviour has been the subject of intermittent regressions over many years. Specific examples — anchors moving between paragraphs unexpectedly, images jumping pages, position properties not preserved on save and reopen — recur often enough that this entry serves as a marker rather than a specific bug record.

The relevant point: Word image positioning is unusually sensitive to interaction between document XML, anchor properties, and the rendering engine. Each major Word update tends to introduce or surface new edge cases in this area. None of the post-2023 image-positioning behaviours has been formally acknowledged by Microsoft as a regression, but the volume of community reports is consistent enough that the absence of acknowledgement is itself a finding.

PowerPoint image-disappearance after save (chronic)

PowerPoint’s behaviour where slides save and reopen with images missing or replaced by red X placeholders is not tied to a single regression. It is a chronic class of failures, most often involving the interaction between OneDrive sync, AutoSave, and very large embedded media. Specific incidents are catalogued in the PowerPoint images disappeared after save article rather than on this timeline.

A notable spike occurred between Q4 2024 and Q1 2025, correlated with changes to the AutoSave conflict resolution behaviour in PowerPoint’s Click-to-Run channel. The user-visible symptom was the same as the long-running chronic issue: images present at save time, missing at reopen. The build-level analysis pointed at an interaction between PowerPoint’s media-cache invalidation and OneDrive’s sync engine, with no single PowerPoint build that could be cleanly identified as the introducer. Microsoft did not formally acknowledge a regression. The chronic class of failures continues.

Excel “Insert Picture in Cell” rollout regressions

App: Excel for Microsoft 365 (Current Channel) Period: Late 2023 through 2024 Status: Largely stabilised through 2025 Symptom: The newer Insert Picture in Cell feature, introduced through 2023, produced multiple distinct failure modes during its initial rollout — images appearing in the wrong cell on filter, images failing to print, images vanishing when the workbook was opened on a version of Excel that did not yet support the feature.

These are not regressions in the traditional sense — they are rollout teething problems for a new feature. Included on this timeline because they affected real user workflows during the rollout period and because the asymmetric version support (newer Excel handles it, older Excel does not) continues to produce intermittent issues when files move between users on different Excel channels.

Word image positioning incidents tied to specific builds

Specific Word builds have introduced or surfaced image-positioning regressions on a roughly annual cadence. Three are worth catalogue entries:

  • Build 16.0.18525+ (Q1 2025): Anchor behaviour regression where images set to “Move object with text” intermittently failed to move with their anchor paragraph when content was inserted before the anchor. Quietly fixed by mid-2025; no formal acknowledgement.
  • Build 16.0.17726+ (mid-2024): Image position properties not preserved when documents were round-tripped through Word for the web. Acknowledged in the Microsoft 365 admin Message Centre but never assigned a Support article.
  • Build 16.0.16xxx series (late 2023): Wrap-style “Through” producing different layout results on save and reopen. Chronic; the underlying interaction between the Wrap Style “Through” option and document conversion code is not robust.

The pattern — Word image positioning regressions arriving roughly annually, taking quarters to fix, often without formal acknowledgement — is worth knowing about even though it cannot be summarised as a single timeline entry.

Patterns worth knowing

Reading across the catalogued regressions, three patterns are persistent enough to be worth stating explicitly.

Classic Outlook absorbs the regression burden disproportionately. Of the image-related Office regressions confirmed by Microsoft in the past eighteen months, an obvious majority sit on Classic Outlook rather than New Outlook, Word, PowerPoint, or Excel. Some of this is structural — Classic is older, more complex, and harder to test at the surface area required. Some of it tracks engineering attention, with the New Outlook codebase visibly receiving more development effort than Classic. The Wrap Text image regression now active is the clearest current example. Microsoft’s framing of New Outlook as “modern” carries with it the implicit framing of Classic as “legacy, on its way out,” and the regression cadence reflects that priority order.

Recovery is slow, even after acknowledgement. The pattern from the catalogued bugs is that acknowledgement to full fix in the Current Channel runs around two to three months. For Semi-Annual Channel customers it is longer still — months become quarters. Organisations whose communications depend on consistent image behaviour should treat the official acknowledgement date as the start of a multi-month workaround period, not as an imminent resolution.

The user-visible behaviour is often broader than the acknowledged bug. This is the most uncomfortable pattern. Microsoft acknowledges narrow, specific symptoms (“images with Wrap Text Top and Bottom do not render”). Affected users report broader symptoms (“images are not appearing at all,” “signatures are broken across the company”). The user reports are not wrong; they are describing the lived experience of the bug across heterogeneous mail clients, where the originating Outlook bug interacts with recipient-side rendering to produce a spectrum of failures wider than Microsoft’s narrow acknowledgement language. Read the Microsoft acknowledgement as the floor of the problem, not the ceiling.

How to use this timeline

This page is built to be searchable, not read end to end. The intended workflow:

  1. You hit an image problem in Office.
  2. You note the app and the build number from File > Account.
  3. You search this page for that build number, or for the symptom.
  4. If your bug is on the list, you have the workaround and the status. If it is not, the timeline tells you it is not a confirmed Microsoft regression — which is itself useful information, because it suggests the cause lies elsewhere (your tenant configuration, a third-party add-in, a recipient-side mail client, or a not-yet-acknowledged regression).

A more detailed walkthrough of how to use the timeline efficiently is in the companion guide, how to use this Microsoft Office image bug timeline.

Sources and verification

Entries on this timeline are sourced from Microsoft’s own support documentation, the Microsoft 365 Admin Centre Message Centre, the Microsoft Office release notes (the Computerworld and Office Watch ongoing logs are particularly reliable on Click-to-Run build histories), and third-party reporting on Patch Tuesday cycles.

Where Microsoft’s own page exists for a regression, the entry links to it directly. Where the only acknowledgement is via the Message Centre (visible only to admins), the MC reference number is given.

Entries are not added to this page based on community reports alone. Reports without official acknowledgement are tracked separately and only promoted to the timeline once Microsoft confirms.

The verification methodology, briefly: each catalogued regression is tested against three sources before inclusion. First, Microsoft’s own Support documentation or Message Centre acknowledgement. Second, at least one third-party publication that has independently observed and reported the symptom (Born’s Tech and Windows World, Computerworld’s Microsoft 365 update log, Office Watch, Neowin, BleepingComputer, and TechRadar Pro are the most reliable). Third, where possible, direct verification by reproducing the bug on a controlled Office installation matching the affected build number. The third step is the bottleneck for entries — some regressions are not reproducible outside specific tenant configurations, and those entries note their reliance on Microsoft’s acknowledgement alone.

Regressions that have been fixed are kept on the timeline rather than removed. The reasoning is that historical search behaviour persists for months after a fix ships — users hit the bug, search for it, and still need to find that yes, it was real, and yes, it has been fixed. Removing the entries would break those searches and leave readers wondering whether they are the only ones experiencing a now-fixed problem.

Next scheduled update: 9 June 2026 (the Tuesday after the June 2026 Patch Tuesday).

If you have a regression to suggest for inclusion, or a fix date that has shipped since the last audit, the timeline is updated monthly and corrections are welcome.

Related reference pages: snipping tool not working on Windows 11, PowerPoint images disappeared after save, New Outlook vs Classic Outlook image handling.