We’d like to inform you about an update to how inline images are represented in the HTML body of Outlook emails in Outlook on the web and the new Outlook for Windows. This change may impact how your add-in identifies and processes inline images when using the attachment ID.
What’s changing?
Previously, inline images in the HTML mail body were represented with a URL containing the attachment ID as a query parameter. The following is an example of an inline image represented in HTML code.
<img src="https://attachments-sdf.office.net/owa/arpitsangwan%40microsoft.com/service.svc/s/GetAttachmentThumbnail?id=AAkALgAAAAAAHYQDEapmEc2byACqAC%2FEWg0AW4xUByFbp0CroCNphMYEEAADMWhyiwAAARIAEAA3P0Tub6RfQaxOX%2Fjz3FlX &thumbnailType=2&token=XYZ… style="max-width: 1281px;" originalsrc="cid:ee058cc2-ad96-485f-95c7-44b2f40cb987" size="19720" contenttype="image/png >
Developers could parse the HTML and do one of the following.
- Extract the ID from the URL and match it with the attachment ID they already had.
- Use the entire URL in the src attribute to get the Base64 value of the inline image.
Going forward, the URL for inline images will no longer contain the attachment ID. Instead, the image will be represented by a content ID (cid) in the src attribute. As a result, your current parsing logic won’t be able to correlate the inline image in the mail body with the attachment ID or Base64 value of the image.
The following sample shows the updated representation of inline images in HTML code.
<img src="cid:ee058cc2-ad96-485f-95c7-44b2f40cb987" style="max-width: 1281px;" originalsrc="cid:ee058cc2-ad96-485f-95c7-44b2f40cb987" size="19720" contenttype="image/png">
Where is it changing?
This update applies to Outlook on the web and the new Outlook on Windows. Other Outlook platforms will continue to operate as they do today.
Why is it changing?
As part of our ongoing security efforts, we’re updating how inline images are loaded. Previously, images were retrieved via a GET request with the token embedded in the URL. We’re transitioning to a fetch call that includes the token in the request header. This change could impact you if you do one of the following to identify where the inline image appears in the message body.
- Parse the attachment ID from the HTML editor.
- Get the Base64 value of the image using the URL in the src attribute.
Solution
To restore inline image correlation, we’re introducing the content ID that represents the image in the src attribute of the corresponding <img> element. Placing the content ID in the src attribute matches how classic Outlook on Windows represents inline images.
Action required
- Update your parsing logic
Instead of extracting the attachment ID from the URL, parse the HTML message body and retrieve the cid value from the src attribute of the applicable <img> element. Then, call Office.context.mailbox.item.getAttachmentsAsync. The getAttachmentsAsync method returns an AttachmentDetailsCompose object that contains the content ID property to help identify and match images. The following is a sample AttachmentDetailsCompose object.
[{"id":"AAkALgAAAAAAHYQDEapmEc2byACqAC/EWg0AW4xUByFbp0CroCNphMYEEAADMWhyywAAARIAEADghOrwhp8zR7umVQRBkN51","name":"image.png","contentType":"image/png","size":2371,"attachmentType":"file","isInline":true,"contentId":"7957e11a-ce80-438b-87cd-611b3d6a3ec4"}]To ensure your add-in continues to correctly correlate inline images during the rollout of these changes, we recommend that your add-in handle both previous and updated implementations. The following code is an example.
- Test your add-in
Ensure your add-in correctly identifies and processes inline images using the updated src attribute.
Timeline
Starting November 15, 2025, the updated inline image representation will begin rolling out to production users. Please make the necessary changes before then to avoid regressions to your add-in experience.
Let us know if you have any questions!
Happy coding!
The Office Extensibility team
Hi team,
would it be possible to make the contentId property also available in the the read mode? We have a scenario where we need to match inline images to attachments and not having the contentId in the AttachmentDetails makes this very hard…
Thanks
Tobias
Hi Tobias,
We already return contentId in AttachmnetDetails for the Inline Images. Here is sample example of response:
[{“id”:”AQMkADZjMDkyMTI5LTRiZWQtNGZhNC1iNzU3LTgyY2U5NzRmNjI5MQBGAAADF7rDZxi9jE6ag7AZmy97eAcAMhkKIjWqDEuDPe98HzeFbgAAAgEJAAAAMhkKIjWqDEuDPe98HzeFbgADh5lm3wAAAAESABAAI3RIoOJllkiNGoRc6jP2Kw==”,
“name”:”image.png”,”contentType”:”image/png”,”size”:59725,”attachmentType”:”file”,
“contentId”:”540e6efe-59c6-4019-9bf4-dc2a8394e056″,”isInline”:true}]
Please verify at your end and let us know if you are facing some issue.
Thanks.
Hi Rupa,
ah! I did not see this in the documentation for AttachmentDetails yet so I assumed it was not available (https://learn.microsoft.com/en-us/javascript/api/outlook/office.attachmentdetails?view=outlook-js-preview).
I’ve checked and can confirm that this is also available in read mode – thanks! Though it does not seem to be available in Classic Outlook for us just yet, is this something that will also be coming to classic Outlook?
Hi Add-ins Team,
We’ve read the recent announcement about changes to inline image representation in Outlook on the web and the new Outlook for Windows, where the attachment ID will no longer be included in the image URL.
In our SharePoint On-Premises environment, we currently use attachments in emails and reference the attachment ID in the src URL to display images in our email headers and footers.
Could you please confirm whether this change will also affect SharePoint On-Premises scenarios, or if it’s limited to Outlook on the web and the new Outlook for Windows?
Thank you for your clarification and guidance.
Hey Youssef,
The changes don’t apply to on-Prem environments. This is limited to Outlook on the web and new Outlook for windows. On-Premises will keep working as before.
Thanks.
The outlook signature will be impacted? If so, how keep compatibility of classic and new outlook?
Hey Douglas,
There won’t be any changes to signature adding process from Addin’s perspective. Although, since the inline image attachment representation in the body will change, The HTML of the signature images will now have cid based images after process completes, as mentioned above. The new HTML that you will see after signature gets appended, will be closer to what we see on classic i.e. ‘cid’ based ‘src’ of ‘img’ tags.
Thanks.
I can see that the Timeline for the rollout starts on 15th November. Is there any indication of when the rollout is due to be completed by?
Has any testing been completed to see how emails received into Dynamics CRM are impacted by this change?
Hi Add-ins Team,
Thank you for providing the recent update. I have another question:
When these changes are rolled out, will the OnMessageAttachmentsChanged event also return the contentId (or cid) value for attachments?
This information will help us determine whether we still need to call Office.context.mailbox.item.getAttachmentsAsync to retrieve the cid when handling this event.
Thank you in advance for clarifying.
Hey Volodymyr,
Yes, OnMessageAttachmentsChanged event would also return the contentId value for attachments.
Please note that the contentId is already being returned today, for getAttachmentsAsync method response as part of AttachmentDetailsCompose object.
To include 'contentId' in OnMessageAttachmentsChanged event, changes have been made and should be available for testing on all production users tentatively in ~2weeks(by the end of 1st week of November) for all production users.
Hi Arpit,
any chance this will also be made available in read mode? In the AttachmentDetails (without compose). Would be extremely valuable for us…
Thanks
Tobias