Using Images in Power BI Paginated Reports - Getting Logos and Photos Right Without Bloating the File

Paginated reports are the ones that have to look right on paper. Invoices, statements, compliance documents, the formal PDF that goes to a customer or a regulator. And the moment a report has to look right on paper, someone wants a logo on it, or a product photo, or a signature image, or a background watermark. Images seem like the most trivial part of building a report, and then they turn out to be the thing that bloats the file, blurs on print, or breaks entirely when the report moves from your machine to the server. I have lost more time to image handling in paginated reports than I would like to admit.

So this is a practical guide to using images in Power BI paginated reports properly, based on the messes I have had to clean up. Microsoft's image use guidance for paginated reports is the reference, and it is worth a read, but the guidance is easier to absorb once you have felt the pain of getting it wrong.

Why paginated reports care about images more than normal reports do

In a normal interactive Power BI report, images are usually decorative and the whole thing lives on a screen. In a paginated report, the image is often part of the official document, and the document gets printed or turned into a PDF at a fixed size. That changes everything. A logo that looks fine on screen can turn into a blurry mess at print resolution. An image embedded a hundred times across a thousand-page statement run can inflate the file into something the server chokes on. The stakes are higher and the failure modes are nastier, because the output is a formal artefact, not a dashboard someone glances at.

For a lot of Australian businesses this shows up in the classic paginated use cases: the invoice with the company logo in the header, the bank or insurance statement with branding on every page, the certificate or compliance document with a signature and a seal. These are exactly the documents where a rendering glitch is not just ugly, it is embarrassing in front of a customer or an auditor.

The three ways to source an image, and when to use each

Paginated reports give you a few options for where an image actually comes from, and picking the right one is most of the battle.

Embedded images are stored inside the report file itself. The upside is that the report is self-contained, nothing external to break, and it moves cleanly from environment to environment. The downside is size. Every embedded image lives in the report definition, and if you embed a large image, the report file gets large, and if that image repeats across many pages it can bloat rendering. Embedded is the right choice for small, fixed things like a company logo that never changes. It is the wrong choice for large photos or anything that varies.

External images are referenced by a URL, so the report points at an image hosted somewhere else and pulls it in at render time. This keeps the report file small and lets you update the image without touching the report, which is genuinely handy when branding changes. The catch, and it is a real one, is that the image has to be reachable from wherever the report renders. This is the single most common way image handling breaks. It works on your machine because the image is somewhere you can see, and then it fails on the server because the server cannot reach that location, or the URL needs authentication the report does not have. If you go external, verify the render environment can actually reach the image, not just your desktop.

Database images come from the data itself, where the image is stored as binary data in a field and the report displays whatever row it is on. This is the one to use when the image is data rather than decoration: a photo that belongs to each product, a signature that belongs to each person, a different logo per business unit. It is more work to set up but it is the correct pattern when the picture is genuinely part of the record rather than fixed chrome on the page.

My rule of thumb: logo and fixed branding, embed it, keep it small. Branding that changes or is shared across many reports, external URL, and test the server can reach it. Anything that varies row by row, pull it from the data. Getting this decision right up front saves the retrofit later.

The sizing and resolution trap

The mistake I see most often is people not thinking about print resolution. Screens are forgiving. Paper is not. An image that looks crisp in the designer can print fuzzy because it simply does not have the pixels to hold up at print size, or the opposite problem, someone drops in a huge high-resolution photo that is far more detail than the output needs and bloats the file for no visible benefit.

The trick is matching the image to its actual rendered size and the output resolution, rather than grabbing whatever file happens to be lying around. A logo that will print at a couple of centimetres wide does not need to be two thousand pixels across. A background image stretched over a full page needs enough resolution to not look soft. Think about where the image will physically sit and how big it will be in the final document, then source an image sized for that. It is not complicated, it is just a step people skip, and skipping it produces either blur or bloat.

Also mind the aspect ratio and how the image sizing behaves. Paginated reports let you control whether an image keeps its proportions, stretches to fit, or clips. Stretch is the enemy of a professional-looking logo, because a squashed or elongated logo screams that nobody checked the output. Keep proportions unless you have a specific reason not to, and actually look at the rendered PDF rather than trusting the designer preview.

Where it gets rough, honestly

A few things about images in paginated reports are genuinely fiddly and worth knowing before they bite.

External image reliability is the big one. As I said, it is the classic works-on-my-machine failure. The report renders perfectly in development and then the logo is a broken-image box on the server because the render service cannot reach the URL or is not authenticated to it. If you use external images, test in the deployed environment early, not the day before go-live.

Performance at scale is the other one. If you are generating large document runs, thousands of statements in a batch, image handling has a real effect on how long the run takes and how much memory it eats. Large embedded images repeated across many pages are the usual offender. When a big paginated run is mysteriously slow, images are one of the first things I look at, and shrinking an oversized embedded image has more than once turned a painful render into a quick one.

And background images specifically can be temperamental across output formats. An image that looks right as a screen-viewed PDF might behave differently when actually printed, or when exported to a different format. If a background or watermark matters to you, test it in the exact format and on the actual output path it will be used in, because the preview is not a promise.

The bigger picture

Images in paginated reports are a small thing that reflects a bigger discipline: paginated reports are formal documents, and formal documents deserve the same care as any other customer-facing output. The businesses that treat their invoices and statements as throwaway technical artefacts end up sending blurry logos and squashed branding to their customers, and it quietly undermines how professional they look. The ones that treat these documents as part of their brand get the details right, and images are one of the most visible details.

If you are building paginated reports for real business documents, invoices, statements, certificates, compliance paperwork, and you want them to look right, render reliably and not fall over at scale, that is squarely the kind of work our Power BI consultants do. And if paginated reporting is part of a wider move onto the Microsoft data platform, it is worth planning it alongside the rest of your Fabric estate rather than in isolation, which is where our Microsoft Fabric consultants come in.

Getting images right is a small, unglamorous part of building documents people trust. If your paginated reports are producing blurry logos, bloated files or the occasional broken-image box in production, those are all fixable and none of them are hard once you know where to look. Get in touch and we will help you get output you are happy to put your name on.