Microsoft’s positioning on the New Outlook for Windows transition has been remarkably consistent for three years now: New Outlook is the future, Classic Outlook is the past, and the migration is happening whether you want it or not. The migration timeline keeps slipping — the original mandatory switchover dates have been pushed back more than once, and Classic Outlook remains a supported client well into the extended Microsoft 365 support window — but the direction of travel is unambiguous.
What Microsoft is less direct about is the practical reality of the differences between the two clients. The marketing language is “modern,” “cleaner,” “faster.” The lived experience, especially around image handling, is that New Outlook drops, changes, or breaks behaviours that users had relied on for two decades.
This is the full inventory of those differences for image-related workflows. Last verified against Classic Outlook Version 2604 (Build 19929.20164+) and the May 2026 New Outlook for Windows release. The verification dates matter because both clients move constantly; if you are reading this more than a quarter after the last_verified date in the frontmatter, expect at least some details to have shifted.
The architectural difference (read this first)
The single most important fact about the two clients is that they are built on different foundations. Classic Outlook is a Win32 desktop application in the original sense — local data store (OST/PST), MAPI as the protocol layer for Exchange, and a COM add-in extensibility surface that the rest of the Office suite shares. It uses Microsoft Word as its HTML rendering engine for message bodies, which is why so many image-positioning oddities in Outlook are actually Word’s oddities surfacing through Outlook.
New Outlook is essentially a packaged web application. The codebase shares heavily with Outlook on the web; the rendering pipeline is a modern browser-engine stack rather than the Word renderer; data is fetched on demand rather than maintained in a local store; and the extensibility surface is the web add-in model, not COM. The user-facing implication of that architectural split is consistent: features that depend on local file access, deep desktop integration, or COM-based extensibility either behave differently in New Outlook, have been redesigned around web-native equivalents, or simply do not exist yet. Signatures, image fetching, and attachment handling all behave more like a web mail client than a desktop application — because that, fundamentally, is what New Outlook is.
Every difference in image handling between the two clients ultimately roots back to that architectural split. Once you understand it, most of the surprises stop being surprising.
The comparison table
| Image behaviour | Classic Outlook | New Outlook |
|---|---|---|
| Signature storage | Local files in %APPDATA%\Microsoft\Signatures (.htm, .rtf, .txt) | Roaming, tenant-side; no local files |
| Signature image rendering engine | Microsoft Word (subject to DPI scaling issues on high-DPI displays) | Modern web rendering; DPI-aware |
| Inline image embedding (default) | Embedded in message body via MIME multipart | Hosted/uploaded; may render via reference rather than embed |
| HEIC image insertion | Supported with HEIF Image Extensions installed; behaves as native image | Different code path; format conversion behaviour varies by source |
| Inline SVG in received messages | Rendered (subject to the standard Outlook image-blocking rules) | Not rendered — disabled September-October 2025 for security |
| SVG attachment in received messages | Supported, opens via default Windows handler | Supported as attachment, viewable from attachment well |
| Drag-and-drop into message body | Embeds as inline picture by default | Behaviour depends on source; web-tech drag-drop semantics |
| Right-click image context menu | Full Office menu including Save as Picture, Format Picture, etc. | Reduced menu; several Classic options absent or relocated |
| Image compression on Send | Configurable via Send Pictures with Document and resolution settings | Not exposed in the same place; defaults to a server-side path |
| Paste Special for image format | Supported via Ctrl+Alt+V with format choice (was broken March-July 2025; now restored) | Limited Paste Special equivalent; mostly default paste |
| Image as separate attachment vs inline | Configurable per send; depends on format (HTML vs Plain Text vs Rich Text) | HTML only; behaviour driven by recipient client interpretation |
| Profile photo cache | Multiple cache locations (OAB, local cache, recipient address book) | Mostly server-side; cache invalidation is faster |
| Active May 2026 regressions | Wrap Text Top and Bottom image dropping (INVESTIGATING) | None acknowledged in this category |
That is the headline. The rest of this page walks through the specific differences in enough depth to act on. If you want the detailed troubleshooting for any individual issue, follow the link at the end of each section.
Signatures
The signature story is the largest single difference between the two clients, and it is where most migrations break.
Classic Outlook stores signatures as local files in %APPDATA%\Microsoft\Signatures. Each signature is three files — an HTML version, a Rich Text version, and a Plain Text version — and any embedded images live in a sibling folder. When you compose a new message, Classic Outlook reads the local files and embeds the image bytes directly into the message body using MIME multipart encoding.
New Outlook does none of this. Signatures live in the tenant, fetched at compose time. There is no local file to back up, no local folder to share between machines. The intended user benefit is roaming — your signature follows you to Outlook on the web, the mobile app, and wherever else you sign in. The cost is that your signature is no longer under your direct control; if the tenant is slow, your signature is slow.
The most acute symptom of this difference is the send-blocking dialog that appears in New Outlook when you try to send before signature images have finished loading. On Classic, this never happens; the image is local, embedding is instantaneous. On New Outlook, the image is fetched asynchronously, and on slow connections you can hit Send before it has arrived. Microsoft has tried to mitigate this with better async handling, but the underlying architecture means the failure mode cannot be eliminated entirely.
For a full walkthrough of how to set up a working signature in New Outlook — including the specific image hosting and sizing decisions that affect both display reliability and compose-time performance — see how to set up a working signature with images in New Outlook.
Inline images: how they get embedded and how recipients see them
Both clients support inline images in the message body, but the implementation differs in ways that show up at the recipient.
Classic Outlook with an HTML message body embeds inline images using cid: references that point to MIME-attached image parts. When this works correctly, recipients see the image inline with no separate attachment. When it goes wrong — and there are many ways it goes wrong — the image either appears as an attachment, displays as a placeholder, or simply does not appear at all. The classic “image shows as attachment for recipients” problem is rooted in this CID-embedding mechanism and the way different recipient mail clients interpret it.
New Outlook handles inline images differently in two important ways. First, where the image originates determines how it is sent — pasted screenshots, drag-and-dropped files, and inserted-from-disk images do not always take the same path through the send pipeline. Second, the web-tech rendering means that the message HTML is more standards-compliant than the Word-engine HTML that Classic Outlook produces, which is paradoxically a problem: many corporate mail filtering rules and legacy mail clients were tuned against Classic Outlook’s quirky HTML output, and standards-compliant HTML can trip those rules in unexpected ways.
The specific failure mode — inline images arriving as attachments for recipients — has different root causes in the two clients. In Classic, the most common cause is plain text format conversion somewhere in the send pipeline. In New Outlook, the most common cause is recipient-side interpretation of the standards-compliant HTML structure. The inline images appearing as attachments in New Outlook article covers the New Outlook side in detail.
The SVG retirement
This is the cleanest difference between the two clients, and it is worth flagging clearly because it surprised many users when it landed.
In September-October 2025, Microsoft retired inline SVG rendering in Outlook for the web and the new Outlook for Windows. The Message Centre announcement was specific: inline SVG would no longer render in New Outlook or Outlook for the web, and recipients would see empty placeholders where the images had been. The change was security-driven, responding to a sharp rise in SVG-based phishing.
Classic Outlook for Windows was not part of the change. Inline SVG continues to render in Classic, subject to the normal image-blocking rules.
For organisations whose brand assets — logos, icons, signature graphics — rely on SVG, this is a real divergence. Recipients on New Outlook see blank spaces; recipients on Classic Outlook see the images. The mitigation is not to switch back to Classic; it is to substitute PNG or WebP for inline SVG in any communications likely to reach New Outlook recipients. SVG attachments remain supported in both clients, but inline rendering is now Classic-only.
Drag and drop
Drag and drop appears similar in both clients but produces different results depending on the source and the destination.
In Classic Outlook, dragging an image file from File Explorer into a message body embeds the image inline. Dragging from a web browser usually embeds inline as well but uses the browser-supplied image data rather than fetching from the source URL. Dragging a screenshot from the Snipping Tool clipboard pastes inline. The behaviour is consistent and predictable across roughly twenty years of Classic Outlook.
In New Outlook, the same operations produce different results. Some sources behave the same as Classic (file from File Explorer embeds inline). Some behave differently (drag from browser may prompt to insert as link rather than embed). Some are inconsistent (clipboard drag-paste from third-party screenshot tools can produce attachment, inline embed, or failure, depending on the screenshot tool’s clipboard format).
The full behaviour map — what each source produces in each destination — is in drag-and-drop image insertion behaviour in New Outlook.
Right-click context menu
Right-click on an image in Classic Outlook produces a deep Office menu: Save as Picture, Change Picture, Format Picture, Edit Picture, and the full set of size, position, and wrap-style options. Most of these have keyboard shortcuts that long-time users have internalised.
Right-click in New Outlook produces a much shorter menu. Several Classic options are absent. Some have moved to the ribbon rather than the context menu. The omissions are not random — they reflect the web-architecture origin of New Outlook, where right-click menus are constrained by the browser’s interpretation of HTML element interactions.
For specific Classic Outlook options that are now missing in New Outlook, and the keyboard or ribbon path that replaces each one, see why right-click image options are missing in New Outlook.
HEIC and modern image formats
Both clients can handle HEIC images, but the path differs.
Classic Outlook leans on the Windows HEIF Image Extensions package. With the extensions installed, HEIC files insert as native images and behave like any other format. Without the extensions installed, HEIC files cannot be inserted from disk — but they can be pasted from clipboard if a different application has done the decode.
New Outlook’s web-tech rendering uses a different code path. The format compatibility list is broader in some ways (WebP and AVIF support is more comprehensive in New Outlook than in Classic) and narrower in others (some HEIC variants from older iPhone OS versions display oddly).
The format-by-format breakdown is in New Outlook HEIC and modern image format support.
Image compression on Send
This is one of the smaller behavioural differences and one of the more annoying for power users.
Classic Outlook exposes Send Pictures with Document and the related image resolution settings through File > Options > Mail > Send messages. These settings let you control the size of outbound images independently of how they appear in the compose window. For users sending large numbers of image-heavy messages, this matters.
New Outlook does not expose the same controls in the same place. The defaults are server-determined. Power users have less control. The trade-off Microsoft has made is “fewer settings, more consistency,” and reasonable people can disagree about whether that is the right trade.
Profile photo behaviour
Profile photos are the smallest of the differences but the source of disproportionate frustration.
Classic Outlook maintains multiple profile photo caches: the Offline Address Book, a local client cache, and a recipient address book cache. Update your profile photo through the Microsoft 365 admin, and the various caches update at different speeds. Some recipients see the new photo within hours; others see the old photo for weeks. The result is the long-standing “I updated my photo but everyone still sees the old one” problem.
New Outlook simplifies this. Profile photos are fetched from the tenant in real time at message render. Cache invalidation is faster. The behavioural difference is small in the abstract — both clients have caching — but in practice New Outlook updates noticeably faster.
For the multi-cache problem on Classic Outlook, see Outlook profile photo not updating across devices.
What the current Classic Outlook bug means for the comparison
As of late May 2026, Classic Outlook has an active, INVESTIGATING image regression: embedded images using the Wrap Text “Top and Bottom” layout option are not displayed for recipients, starting with Version 2604 Build 19929.20164. The image may include a red x and an error, but not in all cases. New Outlook is not affected by this bug.
There is a temptation to read this as a clean win for New Outlook in the comparison. That reading is too simple. The regression is a current, fixable bug. The structural differences in this comparison are permanent architectural decisions. New Outlook being unaffected by one current Classic bug is real but transient information; the architectural differences in the comparison table will still matter long after the Wrap Text issue is fixed.
The full status of the Wrap Text regression and other active Office image bugs is tracked on the Microsoft Office image regression timeline.
So which one should you use?
Microsoft’s answer is New Outlook, and the migration pressure will continue. The honest answer, for image-handling workflows specifically, is more nuanced.
Use Classic Outlook if: Your workflow depends on COM add-ins, PST archives, shared mailboxes with strict offline access, or any of the features that New Outlook still lacks. Your signature is mission-critical and you need it under direct local file control. Your organisation has invested heavily in HTML email templates tuned against Classic Outlook’s rendering behaviour.
Use New Outlook if: You are starting fresh and have no legacy dependencies. You want roaming signatures and consistent behaviour across desktop, web, and mobile. Your image-handling needs are simple inline images and standard signature graphics. You can live without inline SVG and the deeper right-click menu.
Switch back to Classic temporarily if: You are hit by a current New Outlook image regression that has no workaround and you are in a delivery-critical window. Switching is reversible. Microsoft has kept the toggle in the upper-right corner specifically so you can switch back during transition issues.
The deeper point is that the comparison is not stable. New Outlook is the active development priority and is gaining features. Classic Outlook is the support priority and is receiving regressions at a higher rate. Eighteen months from now, the comparison table will look different. The architectural split — desktop application versus web-architecture — is permanent, but the specific feature-by-feature comparison will shift.
If you are making a migration decision now, make it on the structural differences (the architectural split, the signature storage model, the SVG retirement) rather than on the current bug list. The current bugs will be different in six months. The structural differences will not.
Companion reading: Microsoft Office image regression timeline for the current state of all known image bugs across Office; how to set up a working signature with images in New Outlook for the specific migration pain point most users hit first; inline images appearing as attachments in New Outlook for the second-most-common migration pain point.
Sources: Microsoft Support documentation (current as of May 2026); Microsoft 365 Message Centre announcements; verified through testing against Classic Outlook Version 2604 (Build 19929.20164+) and the May 2026 New Outlook for Windows release.