Power BI Page Size and Display Settings - Getting Reports to Actually Fit

Here's a complaint I hear at least once a month from teams we work with: "The report looks perfect on my screen, but when the boss opens it on her laptop it's got scroll bars everywhere and half the chart is cut off." Nine times out of ten, the culprit isn't the data or the visuals. It's the page size and display settings, which is the most quietly important part of report design that almost nobody thinks about until something looks broken.

Page size sounds like the dullest topic in Power BI. It's a couple of dropdowns in the formatting pane. But getting it wrong is the difference between a report that looks sharp on every screen and one that looks amateurish on anything other than the machine it was built on. So let me walk through what these settings actually do, how to choose, and the traps that catch people out.

Why this matters more than it looks

A Power BI report page has a fixed canvas. You design your visuals onto that canvas, and then Power BI has to decide how to show that canvas on whatever screen the viewer is using, which is almost never the same size as yours.

This is the bit people miss. You build your report on a big monitor. It looks great. You publish it. Then someone opens it on a 13-inch laptop, or embedded in a Teams tab, or on a phone, and the relationship between your canvas and their screen is completely different. Whether that experience is good or terrible comes down to the page size and the scaling option you chose, usually without thinking about it.

We run a lot of Power BI training for Australian teams, and this is one of those topics where ten minutes of explanation saves people from months of reports that "just look a bit off" without anyone being able to say why. The settings are simple. The consequences of ignoring them are not.

Page size options

In the Format pane, with no visual selected so you're formatting the page itself, you'll find the canvas settings. The main choice is the page type, and the defaults are worth understanding.

The standard default is 16:9, a widescreen ratio sized for a typical monitor. For most reports consumed on a screen, this is the right starting point and you can leave it alone. It matches how people actually view reports, so visuals fill the space sensibly.

There's also a 4:3 option, the older, more square ratio. You'll rarely want this now unless you're matching some specific legacy display or a print format that needs it.

And then there's custom, which lets you set the exact pixel dimensions of your canvas. This is where the power is, and where the trouble starts. Custom sizing is genuinely useful when you've got a specific target, like a report designed to be embedded in a particular spot on an internal portal, or a tall, narrow layout meant for scrolling rather than fitting on one screen. But custom sizing is also how people accidentally build reports that work nowhere except their own monitor, because they set the canvas to match their screen and forget everyone else's is different.

My rule of thumb: stick with 16:9 unless you have a concrete reason not to. A "concrete reason" is a known target environment with known dimensions, not just "it looked nicer wider on my screen."

The display and scaling options

This is the part that actually controls how your report behaves on a screen that isn't yours, and it's the setting most people never touch. Under page view, you've got a few ways the canvas can be fitted to the available space.

Fit to page scales the whole canvas up or down so the entire page is visible at once, no scroll bars. The trade-off is that on a small screen everything shrinks, and on text-heavy reports it can get hard to read. But nothing is hidden, and there are no scroll bars, which for most business reporting is exactly what you want. People want to see the whole picture without scrolling around hunting for the bit they need.

Fit to width scales so the page fills the width of the available space, and lets the report scroll vertically if it's taller than the screen. This is the one to reach for when you've deliberately built a tall report, the kind of long scrolling page that works well for detailed dashboards where the viewer expects to scroll down through sections.

Actual size shows the canvas at its true pixel dimensions and adds scroll bars if it doesn't fit. I'd avoid this for most shared reports. It's the setting most likely to produce that "scroll bars everywhere" experience for someone on a smaller screen, because it makes no attempt to adapt to the space available.

For the vast majority of business reports that get viewed across a mix of devices, fit to page is the safe default. It's the one that most reliably gives everyone a sensible view regardless of their screen, and it's what I'd set unless there's a specific reason to do otherwise.

The mobile layout people forget exists

Here's a feature that's been in Power BI for years and that I'd guess fewer than one in five report authors actually use: the mobile layout view. It lets you design a completely separate layout for how your report appears on a phone, rearranging the visuals into a tall, single-column arrangement that actually works on a small screen.

If a meaningful number of your users open reports on their phones, and more do than you'd think, especially executives and field staff, this is worth the effort. Without a mobile layout, phone users get the desktop canvas squeezed onto a tiny screen, which is the squinting, pinching, zooming experience that makes people give up on a report entirely. With one, they get something built for the device in their hand.

It's extra work, no question, and I wouldn't bother for every report. But for the handful that genuinely get heavy mobile use, designing a proper mobile layout is one of those things that separates a report people tolerate from one they actually rely on. We cover this in our hands-on training sessions because it's exactly the kind of feature that's hard to stumble onto but transforms the experience once you know it's there.

The mistakes we see most

A few patterns that come up again and again when we review clients' reports.

Building for your own monitor. The single most common one. The report was designed on a large, high-resolution screen, set to actual size, and it falls apart on anything smaller. Always test your report on a screen smaller than the one you built it on before you call it done. If you've only got the one screen, resize the browser window right down and see what happens.

Custom canvas sizes with no reason. Someone set a custom pixel size early on, often by accident, and every visual got laid out against it. Later, nobody remembers why the report behaves oddly, and the answer is a canvas dimension that doesn't match anything. If you don't have a specific target in mind, don't go custom.

Cramming too much onto one page. This isn't strictly a settings issue, but it shows up here. People build an enormous canvas to fit everything, then wonder why fit-to-page shrinks it all into unreadable tininess. Often the real fix isn't a display setting at all, it's splitting one overloaded page into two or three focused ones. A report that needs a giant canvas to fit is usually a report trying to do too much.

Ignoring the viewer entirely. The deeper mistake underneath all of these. The author designs for themselves and never asks who's actually going to open this, on what, and where. Two minutes of thinking about your real audience, their devices, and where the report will live saves a lot of "why does it look broken" later.

The bottom line

Page size and display settings are dull right up until they make your report look broken, and then they're the only thing that matters. The good news is the right defaults cover most cases: 16:9 canvas, fit to page, and a mobile layout for the reports that genuinely need one. Reach for custom sizing and the other scaling modes only when you've got a specific target you're designing for.

The real skill isn't memorising the options. It's remembering that your screen isn't your audience's screen, and designing for theirs. That habit, more than any single setting, is what makes the difference between reports that look professional everywhere and reports that only look right on the machine they were born on.

Power BI rewards people who learn it properly, and these unglamorous settings are a good example. They take ten minutes to understand and they quietly fix a problem that otherwise nags at every report you build. If your team's reports have a habit of looking great in the demo and rough in the wild, that's usually a sign some focused Power BI training would pay for itself fast. Get in touch and tell us where your team's at.

Reference: Apply page size and settings, Power BI documentation.