Power BI Supported Browsers - Why the Boring Compatibility Question Still Bites Australian Teams

Here is a support ticket I have seen more than once, in slightly different words each time. "The dashboard is broken." You open it on your machine and it works perfectly. You ask what they are doing and it turns out they are viewing it on an old browser on a locked-down corporate desktop, or on a tablet in a warehouse, or through some embedded view inside another application. The report is fine. The browser is the problem. And browser compatibility is one of those unglamorous topics nobody thinks about until it produces a confusing bug that wastes an afternoon.

So this is the boring but genuinely useful post about which browsers Power BI supports, why it matters more than you would think, and where Australian teams get caught. Microsoft keeps the authoritative list in its supported browsers documentation, and browser support does shift over time, so bookmark that. What follows is the practical read on what the list means for you.

The short version

The Power BI service runs in a modern web browser, and the ones Microsoft supports are the current versions of the mainstream browsers: Microsoft Edge, Google Chrome, Safari on Mac, and Firefox. On mobile there is Safari on iOS and Chrome on Android, though for phones and tablets you are usually better off in the dedicated Power BI mobile apps than in a browser anyway.

The word doing the heavy lifting there is "current." Power BI supports the current version of these browsers, which means an old, un-updated browser is not really supported even if it is technically one of the right products. This matters in organisations where browsers do not auto-update because IT controls the version, which is a lot of larger Australian enterprises and most of government.

Internet Explorer is gone, and some places have not caught up

Internet Explorer is no longer supported, full stop. Microsoft retired it, and Power BI does not support it. This sounds like ancient history until you actually work with certain organisations. I have been inside Australian businesses in the last couple of years, government bodies and older enterprises in particular, where Internet Explorer was still installed, still the default for some internal system that was built against it years ago, and still what a chunk of staff instinctively opened.

If that is your environment, a Power BI report opened in Internet Explorer will either not work or work badly, and the user will report the dashboard as broken when the dashboard is completely fine. The fix is not in Power BI. It is getting those users onto a supported browser, which is usually Edge since it is already on every Windows machine. Worth knowing before you spend an hour debugging a report that has nothing wrong with it.

Edge is the natural landing spot here. It is built on the same engine as Chrome now, it is on every Windows install, and it is fully supported. For most Australian corporate environments, standardising report viewers on Edge or Chrome removes an entire category of support tickets. It is a genuinely cheap win.

Where browser issues actually show up in practice

In my experience the compatibility problems cluster in a few predictable places, and none of them are "someone at home on a normal up-to-date Chrome," which basically always works.

The first is locked-down corporate desktops where IT pins an old browser version for stability. The report needs a current browser and the machine has a frozen one. This is a conversation with IT, not a Power BI problem, but you need to recognise it for what it is rather than chasing it in the report.

The second is embedding. When Power BI content is embedded inside another application, a portal, an intranet, a custom app, the behaviour depends on the browser or the embedded browser control that host is using. Embedded scenarios are where I see the weirdest, hardest-to-reproduce issues, because the host application might be using an old rendering engine under the hood even when the user thinks they are on a modern browser. If you are embedding Power BI, test in the actual host environment, not just in a clean browser tab, because the clean tab lies to you about what your users will experience.

The third is browser extensions and aggressive security settings. Ad blockers, script blockers, strict privacy configurations and some corporate security tooling can interfere with Power BI, which relies on scripts and network calls to function. When a report misbehaves for one specific user on a supported browser and works for everyone else, an extension or a security policy is very often the culprit. Testing in a private or incognito window, which disables most extensions, is my go-to first diagnostic. It takes ten seconds and it splits the problem in half.

The fourth is mobile-in-a-browser. People try to view reports on a phone or tablet through the browser and find the experience cramped and clunky. That is not really a support gap, it is that reports viewed in a mobile browser are a poor fit. The answer is the Power BI mobile apps, which are designed for touch and small screens, plus building an explicit mobile layout for reports that genuinely need to be used on the go. If you have field staff, warehouse workers or anyone using reports away from a desk, plan for the mobile app rather than hoping the browser experience is good enough, because it usually is not.

Why this deserves a moment of planning

It is tempting to treat browser support as beneath attention, and for a small team where everyone runs current Chrome it basically is. But the moment your report has a broad or non-technical audience, the assumptions break. You do not control what your viewers are running. Some are on old locked browsers, some are on tablets, some are behind security tooling that fights your report, and every one of them will report the same symptom: "it does not work," with no useful detail.

The practical move is to know your audience's environment before you ship anything important. Ask what browser the organisation standardises on. Ask whether Internet Explorer is still lurking anywhere in the workflow. Ask whether people will view this on phones. Ask whether it is going to be embedded in another system. Those four questions, asked up front, prevent most of the browser-related surprises that otherwise land after go-live when they are most expensive and most embarrassing to sort out.

This is the kind of unglamorous groundwork that separates a report deployment that goes smoothly from one that generates a week of confused support tickets, and it is part of what our Power BI consultants think about when planning a rollout rather than just building the visuals and hoping.

The honest assessment

Power BI's browser support is genuinely good and rarely the actual cause of a problem for anyone on a current mainstream browser. Chrome, Edge, Safari and Firefox in their up-to-date versions all work well, and Microsoft keeps the platform current with web standards. So I do not want to overstate this. In the great majority of cases, browser compatibility is a non-issue.

The trouble is concentrated at the edges, and the edges are exactly where enterprise and government users live: frozen browser versions, embedded contexts, security tooling, and mobile-in-a-browser. Those are the situations where knowing the supported-browser reality saves you from debugging a report that was never broken. The single most useful habit is simply to reproduce the problem in the user's actual environment before assuming the report is at fault, because most of the time it is not.

If you are rolling Power BI out across an organisation with a mix of devices, locked-down desktops and non-technical users, and you want it to land cleanly rather than generate a pile of "it does not work" tickets, that planning is worth doing properly. Have a look at our data and analytics services, or get in touch and we will help you get a deployment that works for your actual users on their actual machines, not just on a clean developer laptop.