How to Create Custom Report Themes in Power BI That Actually Look On-Brand

Walk into any large Australian organisation that has been using Power BI for a few years and you will find the same thing: forty reports, and no two of them look like they came from the same company. One uses the default blue-and-orange palette Power BI ships with. Another has whatever colours the analyst grabbed off the corporate website that day. A third is a rainbow of hardcoded hex values that someone typed in visual by visual. The logo placement is different on every page. The fonts are a lottery.

None of this is a disaster on its own. But it quietly tells everyone who opens these reports that the reporting function is a bit ad hoc, and it means every new report starts from a blank slate where the author re-decides colours and fonts they should never have to think about. Custom report themes fix this, and they are one of the more underused features in Power BI given how little effort they take once you understand them.

Microsoft's guide to creating custom report themes covers the mechanics. Here is the version shaped by actually rolling themes out across organisations, including the bits that matter more than the docs let on.

What a theme actually controls

A Power BI theme is a set of defaults that apply across an entire report. At the simple end, it controls the colour palette, the eight data colours that get assigned to your bars, lines, and slices, plus the colours for good, bad, neutral, and so on. At the detailed end, it controls almost everything: fonts and sizes for titles and axes and labels, background colours, borders, padding, the visual header, even the styling of specific visual types.

The point is that you set these once, at the report level, and every visual inherits them. Add a new bar chart and it already has the right colours and the right font. You are not formatting it. You are just using a chart that already looks correct. Multiply that across dozens of visuals and dozens of reports and the time saved is real, but the bigger win is consistency you get for free instead of consistency you have to police.

Starting simple with the theme dialog

You do not have to write anything to get started, and I would not begin with JSON either. In Power BI Desktop, under the View ribbon, you can customise the current theme through a dialog. Set your primary brand colours, pick your fonts, choose the accent colours, and save it. For a lot of teams that is genuinely enough. You get a .json theme file out the other end that you can share and reuse.

The dialog is the right place to start because it shows you the effect immediately and it stops you fiddling with a raw file before you understand what each setting does. Get the palette and the fonts sorted here, save the theme, and apply it to a report to see how it lands on real visuals. Colours that look great as swatches sometimes look terrible as a stacked bar chart with eight categories, and you want to find that out early.

When you need the JSON

The dialog does not expose everything. When you want fine control, styling every visual type, setting default padding, controlling the visual header, matching a detailed brand guide, you edit the theme JSON directly. This is where themes go from "nice palette" to "our reports genuinely look designed".

A theme file is a JSON document with a name, a set of data colours, and a visualStyles section where you can set defaults for specific visuals and specific properties. You can say "all card visuals use this font at this size", or "all charts have no border and this background", or "the default text is this exact grey". The structure is verbose and a bit fiddly, and the property names are not always intuitive, but you write it once and reuse it forever.

My honest advice: do not try to author the full JSON from a blank file. Export a theme from the dialog first so you have a valid structure with your colours already in it, then extend that. Building the whole thing by hand from the schema reference is a good way to spend an afternoon chasing a missing bracket. Start from something that works and add to it.

One rough edge worth flagging. The theme JSON schema is large, has changed over time, and is not brilliantly documented for the deeper properties. You will occasionally set something that does not take effect, or that behaves differently from what you expected, and there is a fair bit of trial and error at the detailed end. It is worth it for a template used across an organisation. It is not worth it for a one-off report nobody else will ever open.

The mistake that undoes the whole thing

Here is the trap, and almost everyone falls into it. You build a beautiful theme, you apply it, and then an author opens a visual and manually sets a colour on a data point because they wanted that one bar to be red. That manual override sticks, and it sits outside the theme. Now when you update the theme later, that override does not move with it, because it was never part of the theme in the first place.

Do this across a report and you have undone the entire benefit. The report looks themed, but half its formatting is hardcoded overrides that will not respond when you change the central theme. You have all the maintenance burden of manual formatting with the false comfort of thinking you are themed.

The discipline is: let the theme carry the defaults, and only override manually when you have a genuine reason, and know that you are creating a maintenance liability when you do. If you find yourself overriding the same thing on every report, that is a signal it belongs in the theme, not in the visual. Put it in the theme and the override disappears.

Treat the theme as an asset, not a one-off

The teams that get real value from theming treat the theme file as a shared organisational asset, versioned and owned, not something each analyst reinvents. There is one canonical theme, or a small set of them, one for internal operational reports, maybe a cleaner one for reports that go to the board or to clients. New reports start from the template that already has the theme applied. When the brand refreshes, you update the theme, redistribute it, and reports pick up the new look with a re-apply rather than a rebuild.

That last point is the quiet superpower. When a brand does a colour refresh, the organisations that themed properly update one file. The organisations that hardcoded everything face going through forty reports by hand, and in practice that means the reports just never get updated and drift further from the brand every year.

There is a limit worth being honest about. A theme controls defaults and styling, but it does not control layout. It will not put your logo in the top corner of every page or arrange your visuals for you. For that you need report templates, .pbit files, which is a related but separate practice. Themes handle how things look, templates handle how a report is structured and what it starts with. Used together they are how you get reports that are consistent in both style and shape. On their own, a theme still gets you most of the way on the visual side.

Where this fits

Custom themes are a small investment with a long tail of payoff. An afternoon setting up a proper theme, and the discipline to actually use it, saves every report author time forever and makes an entire reporting estate look like it belongs to one organisation rather than forty individuals. It is one of the cheapest ways to make a Power BI platform feel professional.

This is part of how we set up reporting to scale in our Power BI consulting work, and it connects to the broader design thinking we bring to a business intelligence practice where consistency and trust in the numbers matter as much as the numbers themselves. If your reports have drifted into forty different looks and you want to pull them back to one standard, that is exactly the kind of tidy-up we do. Happy to have a chat about getting a theme and a template standard in place.