In November 2025 I posted that the Power BI default canvas size was too small, that I had wasted my whole first year of report building on it, and that everybody should upsize. About 89,000 people saw it. More than fifty of them left a comment, and a good number of those told me I was wrong.

Ten months later Microsoft changed the default.

That is not a victory lap. The people arguing against me were making a better argument than I gave them credit for at the time, and most of what they said survives the change.

So this is the long version. What the default is today, how it got there, what the downstream bill looks like, what the thread was actually arguing about, and what the honest recommendation is once you have added it all up.

One correction first, because it caused half the confusion underneath the original post. I wrote “1600 by 900” and labelled it height by width. 1600 is the width. The Canvas settings card in Power BI lists Height above Width, which is the opposite order to the one everybody says out loud, and you can watch that ordering trip people up all the way down the comments. The graphic I posted has the same problem: the caption I burned into it says 1080 x 1920, and the settings panel next to it clearly reads Height 1100, Width 1800.

What the default is now

Start a new report in Power BI Desktop today, or in the service, and the first page you get is 1920 x 1080.

That comes from the base theme rather than from the canvas settings directly. New reports now start on a base theme called Fluent 2, and Microsoft’s documentation on visual defaults states it plainly: under Fluent 2, new pages default to 1920×1080, “giving you more space”. The old 1280 x 720 has not been deleted. It is simply not where you start any more. It survives as the entry labelled HD in the Size dropdown.

1920 x 1080 has 2.25 times the area of 1280 x 720. Same aspect ratio, same shape, more than double the room.

There are now three base themes to know about:

Now the part that matters more than the number: the new default applies to new pages only. Microsoft is explicit about it. Existing reports and existing pages do not update their page size when you switch base theme, and only new pages use the new default canvas size.

Read that once more with a real report in mind. Take a report built in 2024 on a 1280 x 720 canvas, open it in a current build, switch it to Fluent 2 for the new visual styling, then add a page. The new page is 1920 x 1080. The eleven pages that were already there are not. Nothing in the interface flags the mismatch, and the reader will only find it when they click from page eleven to page twelve and the whole report visibly jumps.

How the change actually landed

It arrived in pieces over six releases, which is worth knowing because a lot of the commentary written in the middle of that window is now out of date.

What a canvas size actually is

Half of the disagreement in the comments came from people meaning different things by the same words, so it is worth being precise before arguing about numbers.

A canvas size is a design grid, not an output resolution. A standard Power BI report page is a fixed rectangle measured in pixels. Every visual on it has an absolute pixel position and an absolute pixel size, set from the top left corner. When the page is displayed, Power BI picks one scale factor for that whole rectangle and draws it at that scale. Nothing reflows. No visual moves relative to any other visual. The picture gets bigger or smaller as one unit.

That is what the Page view setting controls, and it is a completely separate idea from canvas size. It lives on the View tab in Desktop, and in the service you open the report, select Edit, then View. There are three options:

Microsoft’s own schema wording is the precise version. Fit to page: the page is scaled so both width and height fit on the current viewport. Fit to width: only width is scaled, height updates to maintain the page aspect ratio. Actual size: no scaling is done, the page is centred relative to the report canvas. The verb throughout is scaled.

Two consequences that catch people out, both documented.

A reader’s page view choice is not saved. If somebody viewing your report in the service switches to Actual size, that choice is gone when they leave. Microsoft’s documented workaround is to capture the view in a bookmark. Worth knowing before you tell a user to “just set it to fit to width”.

The stored setting is a different question. In the enhanced report format the choice is written per page into page.json as displayOption, alongside height and width. Whether that stored value is honoured for readers of the published report is not documented on Microsoft Learn either way, so test it on your own tenant rather than assuming.

While we are in the schema, one number worth pinning down. The maximum canvas dimension is 9,999 pixels in each direction. That figure has circulated for years as folklore, traced back to a community forum post where somebody reported that 10000 was rejected and then asked whether 9999 was therefore the cap, and nobody ever answered. The interface answers it. Type 99999 into Width in the Canvas settings card and the box refuses it with “Value must be less than or equal to 9,999.”

Worth knowing where that limit lives, though, because it is not in the file. The PBIR page schema puts no minimum and no maximum on height or width at all, and Microsoft documents no ceiling anywhere. The only hard constraint in that schema file is a fifty character cap on the page name. The 9,999 is the number box in Desktop, not the format underneath it.

The three places you can set it

My original post only ever described one of these, which in hindsight is most of why the thread filled up with people describing their own process instead. There are three, and they differ in scope rather than in what they do.

There is a fourth, which is a .pbit template with the pages already sized. That is a different kind of answer and it is the one a couple of people in the thread were quietly describing when they talked about standardised starting points.

The Canvas settings card, in full

The Type dropdown offers five options and has done for years: 16:9, which is the default, 4:3, Letter, Tooltip and Custom. Pick a standard aspect ratio and the Size dropdown gives you presets. For 16:9 those are:

• 1280 x 720, labelled HD. The old default.
• 1920 x 1080, labelled Full HD. The new default.
• 2560 x 1440, labelled QHD.
• 3840 x 2160, labelled 4K UHD.

Pick Custom instead and you type a height and a width in pixels. Vertical alignment has two settings, Top and Middle, and it decides where the page sits in the frame when there is spare vertical room.

Microsoft publishes no pixel dimensions for the 4:3, Letter or Tooltip presets, so I am not going to invent them. Select one and read the numbers off your own build.

The theme JSON, since nobody documents it

This is the one to reach for on a team, and it is genuinely undocumented. Microsoft confirms that a custom theme can carry a default page size and that it applies to new pages, but the article on creating custom report themes still describes a theme as four components, colours, structural colours, text classes and visual styles, with no mention of page settings at all. The property names exist only in the schema file.

They do not live at the top level. A top-level page key fails validation outright, because the schema sets additionalProperties to false at the root and has no page property there. The block goes under visualStyles:

{
  "name": "House Theme",
  "visualStyles": {
    "page": {
      "*": {
        "pageSize": [
          {
            "pageSizeTypes": "Custom",
            "pageSizeWidth": 1600,
            "pageSizeHeight": 900
          }
        ]
      }
    }
  }
}

pageSizeTypes takes one of five values, and they are the internal names rather than the labels you see in the dropdown: Widescreen for 16:9, Standard for 4:3, Letter, Tooltip and Custom. Same five options, different words.

Two honest caveats on that snippet. It validates against the published schema, but Microsoft publishes no worked example of it anywhere, so treat it as a starting point and confirm it on your own build before rolling it out. And if you would rather not hand author JSON at all, the reliable route is to set it in the Theme pane, then use Export theme under Theme settings and read the block back out of the file it writes.

The report theme JSON schema github.com/microsoft/powerbi-desktop-samples

The newest schema published there as of September 2026 is reportThemeSchema-2.157.json, which maps to the August 2026 Desktop build. While you are in it, one naming trap that has nothing to do with canvas size but will cost you an afternoon: outspace is the wallpaper and background is the page background. Two different surfaces, and the JSON name for the wallpaper does not contain the word wallpaper.

What the comments looked like sorted into camps

For my LinkedIn post, the comments fell into four camps.

The biggest camp agreed and named a size. The sizes people volunteered, across the whole thread: 1920 x 1080 more than any other, then 1600 x 900, 2000 x 1000, 1080 x 900, and one person running 1000 x 1280 specifically because their users are on 22.5 inch monitors. Reasons given were consistent: clients want more visible at a glance, fewer scrollbars, a wider usable range of font sizes, and large screens or wall displays to fill. One person argued for making width and height equal, which I had never considered and still have not worked out a use for.

A smaller camp told me to leave it alone, and drew a lot of agreement doing it. That case is worth its own section, below.

A third camp ignored the number entirely and talked about process. Standardised templates with a predefined canvas size per page type. Centralised themes and shared assets. One person described changing sizes ad hoc across a report until it became a total mishmash with no consistency. Somebody else uses bookmarks to compress a page’s worth of content onto one screen, and my honest answer there has not changed: bookmarks are hard to maintain and I deliberately limit how many I put in a report.

And a fourth group asked questions that nobody in the thread answered. Four of them, specifically:

• Does Power BI auto resize, so that none of this matters?
• What is the best canvas size for the mobile app, given how much of the screen goes to wasted side margins?
• What is the best canvas size for a report embedded in a SharePoint page?
• Having changed the canvas size on a report that already exists, how do you realign everything without doing it by hand?

At the time I answered the last one with a shrug and some version of “there is no easy way”. There is now a real answer, and all four are covered below.

The case for leaving the default alone

The comment that drew the most agreement disagreed with the post. It came from somebody with decades of design experience behind them, and the position was that they use the default about ninety per cent of the time. My instinct at the time was to explain why they were wrong. I now think about half of it is right.

Your readers are not on your monitor. You are building on a developer machine, probably a good one, quite likely with a second screen. Your audience is on a mixed fleet of laptops, docked setups, tablets and whatever is bolted to the wall in the warehouse. Statcounter’s worldwide desktop figures for August 2026 put 1920 x 1080 in front at 22.2 per cent, followed by 1536 x 864 at 6.75, 1366 x 768 at 5.25 and 2560 x 1440 at 2.48. In the United States 1920 x 1080 rises to 30.45 per cent. There is no single screen to design for.

And those numbers are not screens anyway, they are CSS pixels. 1536 x 864 is not a panel anybody manufactures. It is 1920 x 1080 divided by 1.25, which is Windows display scaling set to 125 per cent. Add the three forms a 1080p panel can take and roughly 32.5 per cent of worldwide desktop traffic is plausibly running on 1080p hardware, well above the headline 22.2. So a meaningful share of your audience has far less usable height than their monitor’s spec sheet suggests. Measured on this machine, Windows 11 with Chrome maximised and the taskbar showing, a 1080p screen leaves roughly 945 CSS pixels of page height at 100 per cent scaling and roughly 728 at 125 per cent.

Scrollbars are not the enemy. This was the part I pushed back on hardest and have since come around on. A vertical scrollbar is a normal interaction that readers already understand. Designing a page so that it never scrolls, on any device, is a constraint you have imposed on yourself, and it is frequently the constraint that makes you shrink everything until nothing is readable.

And the scaling controls interact. There are at least three of them stacked on top of each other: Page view in the report, browser zoom, and Windows display scaling. Microsoft documents browser zoom in terms of the container rather than the content, and practitioners have reported for years that under the default Fit to page view, browser zoom appears to do nothing to the report itself. That behaviour is not documented on Learn, so test it rather than quoting me on it. If you have ever had a user insist that zooming did nothing, this is probably why.

A second dissenting comment, also well received, argued that oversizing invites clutter: more room means more visuals, weaker hierarchy, smaller numbers and more cognitive load, and the right tools for density are drillthrough pages, tooltips and additional pages rather than a bigger rectangle. I think that is correct as a description of what usually happens and incorrect as an argument about canvas size. A bigger canvas does not create clutter. It removes the excuse for not having any whitespace. But I have seen enough 2400 pixel wide reports crammed to the edges to know which way most people spend it, mine included.

The case for going bigger

Here is what the default actually costs you when it is too small, and why I still think upsizing is the right starting move most of the time.

Visual sizes are absolute, so a small canvas is a small budget. Every visual on the page has a pixel height and a pixel width. On 1280 x 720 you have 921,600 pixels to spend. Take out a title bar, a slicer row and the gaps between cards and you are placing charts into a few hundred pixels of height each. That is where the “everything is tiny” complaint actually comes from, and it is arithmetic rather than taste.

Fit to page means a bigger canvas is not automatically a smaller font. This is what gets lost. Under the default page view, the page is scaled as one unit. Double the canvas and double every font size and every visual, and the reader sees exactly the same thing they saw before, because the scale factor halves to compensate. Going bigger only shrinks your text if you go bigger and then leave the text where it was.

Which is the reason to upsize. It is not that bigger is better. It is that a bigger grid gives you more granularity to place things on, and you can spend that granularity on whitespace and alignment instead of on more visuals.

And 16:9 on a 16:9 world is the safe shape. The default aspect ratio is right. It was the pixel budget that was wrong, and Microsoft agreed by keeping the shape and quadrupling nothing about it except the resolution.

Does anything auto resize

This was the first unanswered question in the thread and the answer is a firm no, with four things that get mistaken for yes.

As of the August 2026 update there is no documented responsive canvas, dynamic layout or reflow feature for standard report pages. Power BI applies one uniform scale factor to a fixed pixel rectangle and centres it. Web page CSS reflow changes what sits where when the window narrows. Power BI changes only how big the whole picture is drawn. Those are different things and the difference is the reason your careful two column layout does not become one column on a narrow screen.

There is a fossil of the old behaviour still in the schema, a displayOption value called DeprecatedDynamic, described as a page with no width or height and marked as deprecated in favour of the other options. The dynamic canvas existed once. It does not now.

What people mean when they say auto resize is usually one of these four, none of which is a responsive page:

So the canvas decision is yours, and nothing downstream will make it for you.

The bill you pay downstream

One of the dissenting comments listed downstream costs as the reason to leave the canvas alone: inconsistent scaling across devices, export problems, and maintenance. That comment was right to raise it, and the specifics are worse and stranger than the comment had room for.

PDF and PowerPoint do not care what size your canvas is

This one surprises people. Microsoft documents the resolution of exported report pages as 1,280 by 720 pixels. That is fixed. It does not follow your canvas.

Set that against a 1920 x 1080 design and you are looking at two thirds of the linear dimension. That is arithmetic from two published numbers rather than a figure Microsoft states, but it is exactly why nine point text that reads fine on screen will not be readable in the PDF. Microsoft also warns, without ever defining the term, that reports with “unusual” custom page sizes may experience issues in export scenarios. Treat that as a reason to test your own size rather than a threshold you can design around.

Some more export detail worth knowing before you promise anybody a PDF:

• Every exported report gets a page margin, a band of white space at the top and bottom of the file. Wallpaper is not exported at all.
• The two export paths disagree about background images. The PDF guidance says use the Fit option for best results. The PowerPoint guidance says remove background images before exporting.
• Each PowerPoint slide is a single static image, so there is no scrolling in it. The PDF documentation makes the same point more usefully for design: a visual with a scrollbar exports showing only what was visible, unscrolled. If your canvas is too small and you solved it with an internal scrollbar, the export silently truncates the data.
• Ceilings: 50 pages and 250 MB on the PDF path, 50 pages, 500 MB, six minutes per page and one hour of total processing on the PowerPoint path.
• Read the applies-to banners. PDF export is documented for Desktop and the service. PowerPoint export is documented for the service only.

Email subscriptions have their own ceiling that is tighter than the manual one: an attachment is limited to no more than 20 pages and under 25 MB. A report that exports cleanly by hand can still be truncated in somebody’s inbox. Attaching a file to a subscription also requires the report to sit in a Premium capacity workspace, or the user to have a Premium Per User licence.

You cannot fix the size at export time through the API either: the export to file API’s ExportReportSettings object has exactly two properties, includeHiddenPages and locale.

The mobile app

The honest answer is that there is no best canvas size for the mobile app, because the mobile app does not use your canvas when you have done the work properly.

A phone layout is a separate canvas that you author by dragging visuals onto it. It is 323 points wide, and Microsoft publishes minimum visual sizes by class: XL at 323 by 270, L at 323 by 180, M at 323 by 100 and S at 158 by 100. Those are points, not pixels, and the class assignments do not follow intuition. Card (New) is classed L while the older Card is S. List Slicer is L. Multi-row card is XL. Check the published table before assuming a visual fits the grid.

Three things worth knowing on top of that:

• A mobile layout only helps in the app. Mobile optimised views display only in the Power BI mobile apps for iOS and Android. Viewed through a web browser on the same phone, reports always display in the standard, non optimised view.
• Without a phone layout, the app falls back to your desktop canvas, and in portrait the reader gets a small version of the whole page. The documented remedies are the rotate view button in the report footer, which arrived in February 2026 and moved to the footer in August 2026, tipping the phone to landscape, or pinch and zoom.
• The auto create engine is blunt by design. It reads the page horizontally, left to right, starting from the top. It cannot handle background images. Too much overlaying defeats it, and with too many images not all of them fit.

So for mobile, the question is whether you are building a phone layout. If you are, the desktop canvas is irrelevant. If you are not, no canvas size fixes it, and the wasted side margins the question asked about are the app letterboxing your landscape page into a portrait screen.

SharePoint and embeds

There is less to go on here than anybody would like.

The SharePoint Online web part exposes a single Display setting, described only as adjusting how the report fits within the SharePoint Online page. The permitted values are not listed. There is no sizing, dimension or aspect ratio guidance on that documentation page at all. The Teams documentation contains none either.

Secure embed is more concrete and slightly self contradictory. It hands you an iframe of width 1080 and height 760, warns that changing the width or height from what is specified may result in certain features not working as expected, and in the next breath tells you that you might need to edit the height and width values to fit your portal page. For what it is worth, 1080 by 760 is roughly 1.42 to 1, against 1.78 to 1 for a 16:9 canvas, so a 16:9 page in a default secure embed frame is going to letterbox. Microsoft does not describe the resulting fit, so plan to test it.

One trap if you were planning to code around it: secure embed’s automatic authentication does not work with the Power BI JavaScript API, and it is blocked in the embedded client SDK from version 2.10.4. So the API’s fitting controls are off the table for a secure embed specifically. Where you do get real control is the full JavaScript embedding API, where ICustomLayout carries pageSize, displayOption and pagesLayout, and you can set each visual’s position, size and visibility explicitly at embed time. That is code you write, not automatic behaviour.

The practical answer to the SharePoint question, then: pick the canvas that suits the report, size the iframe to match its aspect ratio, and accept that you are going to iterate on it in the browser. Nothing published gives you the number.

Does a bigger canvas slow the report down

One of the comments listed performance among the costs of a large canvas. It comes up constantly, so I went looking for the source.

There is no documented penalty for a larger canvas. Microsoft’s own article on report page settings covers Type, Size, Vertical alignment and Page view and never mentions performance once. The optimisation guide, the monitoring guide and the troubleshooting guide are the three articles Microsoft lists about report performance, and between them there is no mention of the size of the report canvas. The troubleshooting flowchart resolves to six possible outcomes and not one of them is a layout or canvas problem. The Well-Architected Framework guidance on performance efficiency for Fabric, which is where an architectural rule about canvas dimensions would live if one existed, says nothing about page size.

What Microsoft does cost is visuals. The optimisation guide recommends limiting the number of visuals on a page to only what is necessary and points at drillthrough pages and report page tooltips as the places to put the rest. Visual cost is measured in data fetched rather than space occupied: the data point limits are set per visual, 500 points for a scatter chart, up to 150,000 for others, with a 150 column cap.

And there is one sentence in the Performance Analyzer documentation that explains most of what gets blamed on canvas size:

Most canvas and visual operations execute sequentially on a single User Interface thread shared by multiple operations, and the reported durations include time spent queued while other operations complete.

The visuals are waiting in line. The measurements of that are worth knowing and worth dating, because the controlled tests on this question are all from 2020. Here they are, and then my own re-run on a current build.

Elements cost, not just data. Chris Webb of Microsoft’s Fabric CAT team timed a page holding a single card visual at 3.7 seconds to interactive on a cold cache, then added 260 rectangle shapes to it. The same page took 24.3 seconds. Replacing the shapes with a page background image brought it back to 4.5. The shapes query nothing at all, which is what makes the result worth carrying into a canvas discussion: the cost was decoration. That is Power BI report performance and the number of visuals on a page, September 2020, never updated.

And the saving is queue time, not engine time. Three months later he isolated it cleanly. Five separate line charts issued five DAX queries and took 710 milliseconds. One small multiples chart showing the same data issued one query and took 486. The individual query times barely moved, 10 to 12 milliseconds either way. Almost the entire difference was the four queries queueing behind each other. See Using small multiples in Power BI to improve report performance.

The one everybody quotes is Marco Russo’s, also 2020: 33 card visuals replaced with three, and 2.7 seconds of user waiting time down to 0.3, a saving he puts at 88 per cent. Read the detail before you repeat the headline. The saving came from collapsing 35 DAX queries to five, and rendering time by itself only fell from 1,331 to 764 milliseconds. It is Optimizing card visuals in slow Power BI reports, and it has aged in two different directions at once.

The finding held up. In a post updated in January 2024, Nikola Ilic took a page of 21 card visuals from over three seconds to about 0.6 by replacing them with a single matrix, and the queue time fell from roughly 3,000 milliseconds to under 300. Same mechanism, four years later, on a much newer build.

The fix did not hold up. Marco’s answer in 2020 was a third party visual, and version one of it is now deprecated. Power BI ships its own answer: the card visual went generally available in the November 2025 release, it replaces both the old single card and the old multi-row card, and Microsoft’s documentation says you can add as many values to one card visual as you like. The documentation also claims, in exactly these words, that combining multiple measures in one visual “improves report performance by reducing visual load time and optimizing underlying queries to the semantic model”.

Notice what that sentence does not say. It does not say one query. Microsoft has never published a query count for the card visual, the generally available announcement makes no performance claim at all, and its own DirectQuery guidance page, reviewed as recently as August 2026, still tells you to consolidate cards into the legacy multi-row card. The claim you will find repeated on a dozen blogs, that one new card visual issues one DAX query for all its values, traces back to a single untested aside in that 2024 post. Nobody has measured it.

So I measured it

I built the test rather than repeat somebody else’s. One import model, 10,000 rows and 13 columns, 72 measures. Twelve pages, all 1920 x 1080. On each page a set of cards showing a label, a callout value, a “vs target” reference label underneath and conditional formatting driving both colours from a measure, because a test made of bare unformatted cards measures something nobody builds. Then the same measures again, in a single card visual, laid out in the same grid at the same tile size with the same fonts. Performance Analyzer on every page, three full runs, Power BI Desktop 2.157.1354.0, the August 2026 build. Every duration below is the median of those three. The separate card rows hardly moved between runs, within about twenty milliseconds. The single card rows moved more, 87 to 143 milliseconds of wall clock at fifteen values, so read the combined column as the right order of magnitude rather than to the millisecond.

Two durations, because they answer different questions. Wall clock is the page render: the first visual starting to the last visual ending. Work is every visual’s own duration added up, which is what the Performance Analyzer list totals. Visuals render concurrently, so work is larger than wall clock, and it is the number that tells you how much the page is asking of that single UI thread.

One card visual issues one DAX query, whatever it holds. Five values, one query. Twenty four values, one query. Identical across all three runs.

So the claim is true, and it is now measured rather than repeated. But read the two duration columns against each other before you go and rebuild anything, because they do not tell the same story. At 24 values the work falls by a factor of 65, from 8,755 milliseconds to 134. The wall clock falls by 3.7, from 396 to 107. Those separate cards are rendering concurrently, so a page that is only doing this is not slow either way: 396 milliseconds is not a report anybody complains about. The work figure is what matters when the page is also carrying the matrix, the two charts and the slicer panel that a real page carries, all of them queueing on the same thread.

Consolidating is not the same as switching visual. Fifteen of the new card visuals took 280 milliseconds. Fifteen legacy card visuals took 166. Both issued fifteen queries, but an equal query count is not equal work, and this is where I have to be careful with my own test: each new card returns three measures in its single query, the callout, the reference label and the colour driving both, while the legacy card has no reference label to draw and returns one. That is not a like for like swap, and it cannot be made into one, because the legacy card will not do a reference label at all. Summed across the page the new cards spent 904 milliseconds more in query and 698 more in render, so the extra cost sits in both phases rather than in drawing alone. Swapping fifteen old cards for fifteen new ones and stopping there still makes the page slower, and what you are buying with that time is the richer card. The saving is in the consolidation, not the visual.

And the card visual runs out of room before most people will expect. Its wrapping grid never draws more than five columns by three rows. I gave a card holding 24 values the entire canvas, 1800 by 900 pixels, and it still drew fifteen tiles and scrolled the other nine. Fifteen values is the practical ceiling for one card. The query count does not change past it, which is worth knowing on its own: at 24 values it still issues a single query, so the nine tiles you cannot see are being fetched and simply not drawn.

Chris Webb’s 2020 shapes result reproduces, and harder. One card visual on an otherwise empty page rendered in 54 milliseconds. The same card with 260 rectangles added took 1,910. That is a 35 times penalty on a page still issuing exactly one DAX query. His 2020 figures were 3.7 and 24.3 seconds, a 6.6 times ratio, but he was measuring Time To Interactive in a browser against the service and I am measuring a warm render in Desktop, so the absolute numbers are not comparable and the ratios are not either. What survives six years and a rewritten rendering stack is the mechanism: objects that fetch no data at all can dominate a page.

Three caveats, because the numbers are only as good as the caveats attached to them. This is an import model of 10,000 rows with trivial measures, so query time is a few tens of milliseconds and what is being measured is mostly the canvas and the queue; a large model with slow DAX will not show these ratios. It is Desktop on one machine, not the service, so there is no network, no capacity and no other users. And they are warm renders after a page switch, not cold report opens. The whole thing is reproducible: the generator that builds the test report, the Performance Analyzer exports from all three runs and the script that drove them are all kept, so the method can be argued with rather than taken on trust.

A bigger canvas costs nothing by itself. What costs is what you put on it, and a bigger canvas is an invitation to put more on it.

So the folklore has it backwards, but only just. The commenter who listed performance was blaming the wrong variable while correctly predicting the outcome, because a 2400 pixel wide page really does tend to end up with more visuals on it than a 1280 pixel one. One caveat before anybody quotes this at a colleague: the absence of documentation is not proof of the absence of an effect. Microsoft has never said a large canvas is free. It has only never listed canvas size among the things that make a report slow.

Rescaling a report you have already built

Somebody asked how to realign a report after changing its canvas size, and I said there was no easy way. There are now two, and the second one is genuinely easy.

The product route

The July 2026 release added the ability to update page size, background colour and wallpaper across all pages at once. If your problem is a dozen sizes that should be one size, that is the fastest fix in the product, and it is the one I should have been able to point at.

Be clear about what it does though. It changes the page size. The release note says nothing about moving the visuals that are sitting on those pages, so expect to land with consistently sized pages and visuals still positioned for the old ones. For a modest size change under Fit to page that is often fine. For a large one it is not.

The PBIR route

If your project is saved in the enhanced report format, the layout is plain JSON on disk and rescaling is arithmetic. A page is a folder holding a page.json with width, height and displayOption, and a visuals folder where every visual has a visual.json carrying a position block:

"position": {
  "x": 20.394,
  "y": 60.295,
  "z": 0,
  "height": 586.995,
  "width": 549.753,
  "tabOrder": 0
}

Multiply the page dimensions and every visual’s x, y, width and height by the same factor and the layout comes out the other side identical, just bigger:

import json, pathlib

SRC_W, SRC_H = 1280, 720
DST_W, DST_H = 1920, 1080
fx, fy = DST_W / SRC_W, DST_H / SRC_H

page_dir = pathlib.Path(r"MyReport.Report\definition\pages\9967b89a7650e74b3a3c")

page = json.loads((page_dir / "page.json").read_text(encoding="utf-8"))
page["width"], page["height"] = DST_W, DST_H
(page_dir / "page.json").write_text(json.dumps(page, indent=2), encoding="utf-8")

for vf in page_dir.glob("visuals/*/visual.json"):
    v = json.loads(vf.read_text(encoding="utf-8"))
    p = v["position"]
    p["x"], p["width"]  = p["x"] * fx, p["width"] * fx
    p["y"], p["height"] = p["y"] * fy, p["height"] * fy
    vf.write_text(json.dumps(v, indent=2), encoding="utf-8")

Five things to know before you run that on anything you care about:

• Close Power BI Desktop first, or apply the external change deliberately. A Desktop save rewrites the whole report definition from memory and never reads back from disk, so a save on top of your edit silently discards it.
• Font sizes do not scale. This is the real catch. Type sizes live in the visual’s formatting properties, not in the position block, so a scaled page comes out with correct geometry and proportionally smaller text. Under Fit to page that is exactly what you did not want. Budget a typography pass afterwards, or the whole exercise gains you nothing.
• If you are changing aspect ratio, use one factor for both axes. Different fx and fy values stretch every visual. Use min(fx, fy) for both and accept an empty band down one side.
• Nothing enforces the page boundary. The schema descriptions say x should sit between zero and the page width, but they are descriptions rather than constraints. You can write a visual clean off the edge of the canvas and the file will still validate.
• Validate and commit before you open it. pbir validate on the report folder, and have the change in git so you can walk it back.

One caveat on the format itself. Microsoft’s documentation still describes PBIR as being in preview. In the service, new reports already use it and the rollout for existing reports began in January 2026. In Desktop, default-on was announced for March 2026, moved to May, and the June notes still described the timing as pending rollout stability checks. So check what your own project is saved as before planning around any of this.

What I would tell a first year developer now

The original post said upsize from the default. The product has since done that for you, which means the advice needs replacing rather than repeating.

Take the new default. 1920 x 1080 is a good canvas. It is the most common screen resolution in the world, it is 16:9, it is a preset rather than a custom number so it is easy for the next person to match, and it has more than twice the room of the thing I was complaining about. If you want one number, that is the number.

Then write it down and hold it. Set it in the Theme pane so new pages in that report inherit it, or in a theme JSON if you are doing this for a team. This is the part that matters far more than which number you picked, and it is the part almost nobody does.

Change it when the report has a reason, not when a page runs out of room. A wall display, a genuinely dense operational screen, a report whose entire audience is on one known device. Those are reasons. “This page needs another two hundred pixels” is how you end up with a report where no two pages are the same size.

If you go bigger, scale the type with it. Fit to page scales the page as one unit, so a bigger canvas with the same font sizes is just smaller text. Decide the scale factor, then apply it to everything.

Check the exports before you promise them. PDF and PowerPoint come out at 1,280 by 720 regardless of what you built, and a subscription attachment caps at 20 pages. The bigger and denser the page, the worse that trip goes.

And build the phone layout if the phone matters. No desktop canvas size is a mobile strategy.

The part I would go back and change in the original post is the certainty. I gave a number as though it were a rule, and the reply people agreed with most came from somebody with far more experience than me, gently pointing out that the rule depends entirely on who is looking at the report. They were right, and the thing that makes their position stronger rather than weaker is that Microsoft has since moved the default in my direction anyway. Both of those can be true. The default was too small, and picking a bigger number was never the hard part.

The original post

If you want the short version, and the comment thread that prompted all of this, it is here:

• One of the biggest mistakes I made in my first year of Power BI

Thanks to everybody who argued with me underneath it. The article exists because the disagreement was better than the post.