Displaying Images in Power BI Tables, Matrices and Slicers - The Practical Guide

A product manager once showed me a Power BI report they had built for their retail buying team and asked why nobody used it. The data was fine. The measures were correct. The problem was that it was a wall of SKU codes and product names, and the buyers, who think in pictures, could not scan it. They wanted to see the product. A row that says "SKU 40381, Navy, $89" means nothing to someone who spends their day looking at merchandise. A row with a thumbnail of the actual jacket means everything. We added product images to the table and usage went up almost overnight. Nothing about the numbers changed. The report just started speaking the audience's language.

Displaying images inside tables, matrices and slicers is one of those Power BI features that sounds trivial and then eats an afternoon the first time you try it, because there is one requirement everyone trips over. Microsoft documents the mechanics on Display images in a table, matrix, or slicer, and this post is the working version: how to actually make it happen, the gotcha that stops most people, and the honest limits you should know before you promise a client a catalogue of thumbnails.

The one thing that matters: it is a URL, not a file

Here is the single fact that clears up most of the confusion. Power BI does not embed image files into your table. It displays images that live at a web address. Your data needs a column containing a URL that points to each image, and Power BI renders whatever is at the end of that link.

That is the whole mental model, and getting it clear saves hours. You are not importing pictures. You are storing web links to pictures, and Power BI is fetching and showing them at report time. Every image has to be reachable at a public or otherwise accessible URL, sitting on a web server, in blob storage, on a CDN, in a SharePoint library, wherever, as long as Power BI can retrieve it over the internet when it renders the visual.

So the real work is almost never in Power BI. It is in getting your images hosted somewhere with stable URLs and getting those URLs into your data model, one per row. If your product images are sitting in a folder on someone's laptop, or worse, pasted into a spreadsheet, you have a hosting job to do first. This is the step that surprises people, and it is worth saying out loud at the start of a project rather than discovering it the afternoon before a demo.

The setting that makes it work: Image URL data category

Once you have a column of URLs in your model, Power BI will not automatically know those links are images. By default it treats a text column as text, so it will show the raw link as a string, and you will get a table full of "https://..." rather than pictures. That is the number one "it is not working" call, and the fix takes about ten seconds.

You select the column in your model, go to the Column tools ribbon, and set its Data category to Image URL. That is the switch that tells Power BI to render the contents as an image rather than print the link as text. Drop that column into a table or matrix and the thumbnails appear. It is genuinely that simple once you know the setting exists, and genuinely baffling until you do. I have watched capable people lose half a day to this one because the documentation buries it and the behaviour gives you no hint about what is wrong.

For slicers there is a related path. An image slicer, letting users filter by clicking a picture rather than a label, is usually done with the built-in slicer set to the right orientation or with one of the image-aware custom visuals from the marketplace, again fed by that same Image URL column. The principle is identical: a column of URLs, categorised correctly, doing the visual work.

Where this genuinely earns its place

The clearest wins are anywhere the audience thinks visually. Retail and merchandising is the obvious one: product catalogues, range reviews, planogram-style layouts where a buyer needs to see the item next to its sell-through numbers. Real estate reports with a thumbnail of each property. Staff directories with photos. Manufacturing quality dashboards where a small image of the defect sits next to the count. In all of these, the image is not decoration. It is the fastest way for a human to recognise the row.

There is a subtler win too. Images turn a table from something people read into something people scan. A merchandiser can flick down a column of product shots far faster than they can parse a column of codes, and their eye lands on the right row before they have consciously read anything. When the goal is recognition rather than calculation, a thumbnail beats any amount of well-formatted text. For teams in this space, it is a small feature with an outsized effect on whether the report gets used at all, and getting reports adopted is half of what a Power BI consulting engagement is really about.

The honest limits

Now for the parts that will bite you if nobody mentions them.

Image size is the first. Power BI renders these images small, and it does not give you fine control over their dimensions in a standard table. The images display at a fixed, modest size suited to a table cell. If you are imagining large, crisp product photography filling the row, adjust your expectations. These are thumbnails. For anything bigger you are looking at custom visuals or a different design entirely, and even then the ceiling is low. Treat this as a "recognise the item" feature, not a "showcase the product" one.

Performance is the second, and it is the one that catches teams out at scale. Every image is a URL that Power BI fetches over the network when the visual renders. A table showing twenty rows is fine. A matrix that could expand to show hundreds of images, each a separate web request, can crawl, especially if the images are large files or the host is slow. The report is only ever as fast as the server holding your images. If you point Power BI at a sluggish image host and render a hundred thumbnails, you get a hundred slow requests and a report that feels broken even though your data model is perfect. Host the images somewhere fast, keep the files small, and do not render more of them on a page than the user actually needs. This is precisely the kind of thing that surfaces in a performance review when a report that flew in development grinds to a halt with real data volumes behind it.

Third, and this one is more of a governance point, those image URLs are a dependency you now own. If the images move, the links break, and your report fills with broken-image placeholders. If the hosting requires authentication that Power BI cannot satisfy, the images will not load for your users even though they load for you. And if the images sit somewhere with different access rules than your report, you can end up with a report someone can open but images they cannot see. Stable, accessible, appropriately permissioned hosting is not an afterthought here. It is the foundation the whole feature stands on, and it needs an owner, because a catalogue of broken thumbnails looks worse than no images at all.

How I would approach it

If you want images in a table, sort the hosting first, before you touch Power BI. Get your images somewhere fast and stable with predictable URLs, and get one URL per row into your data. That is the real project. The Power BI side is a single data-category setting and a column drag.

Then be honest with yourself about scale and expectations. Thumbnails, not hero shots. A sensible number of rows on a page, not a thousand. A fast host, not a spare server nobody maintains. Get those three right and the feature is a quiet delight that makes reports genuinely more usable for visual audiences. Get them wrong and you have a slow report full of tiny broken pictures, which is a worse result than the plain table you started with.

The broader lesson, and it is one that comes up across a lot of our Power BI work, is that the impressive-sounding features are usually easy in Power BI and hard everywhere else. Rendering an image is one setting. Sourcing, hosting, permissioning and maintaining thousands of images so that setting has something good to point at is the actual work, and it is the part that decides whether the feature helps or embarrasses you. If you are weighing up putting images into reporting at any real scale, that hosting and data-quality groundwork is exactly where we tend to start, and it is a big part of what a proper business intelligence engagement is spending its time on. Sort the plumbing, flip the setting, and let your buyers finally see the jacket.