BCAIHUB — Business Central & AI Consulting

For years, previewing an image attachment inside Business Central meant one of two things: download the file and open it somewhere else, or build a previewer yourself. Many partners built one. A JavaScript control add-in, a Base64 image viewer, a SharePoint-backed preview page. The community shared these patterns openly, and they solved a real problem that the platform hadn’t yet addressed.

Version 29 addresses it natively, and that changes what those custom previewers are worth.

Where This Started

Business Central 2025 release wave 1 introduced native PDF preview in the web client, with no control add-in and no extra APIs required. Files opened in a viewer similar to print preview, with a download option inside it. It became the standard experience for document attachments and incoming documents.

That native support stopped at PDFs. Images were left out, which is exactly why the custom-previewer patterns existed.

What Version 29 Adds

Image attachments now open directly in the web client without downloading first, in the same viewer experience. From the viewer you can download a copy, and you can print the image directly from the client.

The supported format list is broad: JPEG, JPG, PNG, BMP, SVG, WEBP, ICO, plus GIF and AVIF including their animated versions. On Safari, TIFF and TIF work as well. Two smaller details are worth knowing. GIFs now work as FactBox thumbnails, animation included, for GIFs up to 48 frames. And thumbnail previews became clickable, for images and for the first page of PDFs, opening the previewer window.

The Detail That Changes the Developer’s Work

Microsoft’s description says the feature works across all areas of Business Central, including agents, email, and code from extensions. The last part has a condition attached: extension developers must add support themselves. On Business Central online, that means calling File.ViewFromStream. On-premises, it’s File.View. Both follow the same pattern as the existing File.Download method.

In practice, the wiring looks like this:

trigger OnAction()
var
    InStr: InStream;
begin
    // load your image content into InStr first
    File.ViewFromStream(InStr, 'photo.png', true);
end;

That opt-in matters. Standard Business Central areas like Attached Documents get the viewer automatically. Anywhere an extension handles files through its own code, the viewer appears only if the developer calls the new method. In preview testing, Incoming Documents did not open images in the viewer by default and fell back to the download prompt, though a small page extension calling File.ViewFromStream on the attachment content made it work. Whether Microsoft closes that gap before general availability is worth checking against the final build rather than assuming either way.

What This Means for Existing Custom Previewers

If you’ve shipped a custom image previewer inside a solution, this is worth a deliberate look. A native viewer means no control add-in to maintain, no JavaScript dependency to keep working across web client changes, and a consistent experience user already recognize from PDF preview.

That doesn’t mean every custom previewer should be removed immediately. Some handle file types the native viewer doesn’t, and some do more than preview. But for the common case, previewing a standard image attachment, the native option is now the lower-maintenance path, and it’s worth auditing which of your solutions still carry the older approach.

Finally

The pattern here is one I keep seeing in this release: the community builds a workaround for a genuine gap, the platform eventually fills the gap, and the workaround quietly shifts from asset to maintenance burden.

That’s not a criticism of the workaround. It’s what made the gap survivable in the meantime. It’s just a reason to go back and check which of the things you built are still doing work the platform now does better on its own.