How to Embed Power BI in Your Web App

To embed Power BI in your web app you have three realistic options, and the right one depends on who your viewers are and whether they hold Power BI licences. Use publish to web only for genuinely public content. Use user owns data when viewers are internal staff who each have a Power BI Pro licence and sign in themselves. Use app owns data, backed by dedicated embedded capacity, when you are building a SaaS product or customer portal where external users should see governed reports without ever holding a Power BI licence or logging in to Power BI. Getting this decision right early saves a painful re-architecture later.

The three embedding patterns

The patterns differ mainly in authentication and licensing, not in how the visuals look.

Publish to web is the simplest. From the Power BI Service you generate an embed code and drop an iframe into any page. It is free, but it is also fully public: the report URL is anonymous, can be shared by anyone, and may be crawled by search engines. It is only appropriate for marketing pages, public sector open data, or sample dashboards. It must never be used for anything confidential.

User owns data (sometimes called "embed for your organisation") embeds reports inside your own internal app, but every viewer authenticates with their own Microsoft Entra identity and needs an appropriate Power BI licence. This is ideal for an internal intranet, an operations portal, or a line-of-business tool used by employees who already have Power BI Pro.

App owns data (often called "embed for your customers") is the SaaS pattern. Your application authenticates to Power BI using a service principal, requests an embed token on the user's behalf, and renders the report. Your customers only ever log in to your app. They do not need Power BI licences, and they never see the Power BI Service. This requires dedicated capacity, which is where most of the cost sits.

Comparison at a glance

Licensing and capacity

Power BI Pro is a low per-user monthly licence and covers user owns data scenarios where viewers sign in. Premium Per User (PPU) is a higher per-user licence that adds premium features for those individuals.

App owns data is different: you pay for capacity, not per user. Historically this meant A-SKUs from Azure (billed hourly and pausable), and increasingly it means Microsoft Fabric F-SKUs. The capacity you choose drives how many concurrent renders and refreshes you can support, so it is sized to load, not headcount. Crucially, embedded capacity is what lets external customers view reports without licences. Microsoft pricing and SKU options change regularly, so confirm current pricing and SKU availability with Microsoft before you commit. For a fuller breakdown see our guide to Power BI Embedded pricing.

Security you must not skip

Embedding is only as safe as your token handling and data model. Generate embed tokens server-side, never expose your service principal secret to the browser, and apply row-level security so that each customer sees only their own data. With app owns data you pass the effective identity into the embed token, and the report filters accordingly. Treat the dataset as a shared tenant database: one mistake in RLS can leak one customer's data to another.

A pragmatic decision path

Ask three questions. Is the audience the public? If yes, publish to web (and only if the data is genuinely public). Are viewers internal staff who already have, or can have, Power BI licences? If yes, user owns data is the cheapest robust route. Are viewers external customers who should never touch Power BI? If yes, app owns data with dedicated capacity is the only sound choice. Most product teams reading this will land on app owns data.

If you are weighing this up alongside a wider platform decision, our Power BI and Microsoft Fabric services cover capacity sizing, gateway setup and CI/CD for embedded analytics. You may also find our modern data stack for SMEs useful for the warehouse layer feeding these reports.

Getting started without over-engineering

A common mistake is jumping straight to large capacity. Start with the smallest viable F-SKU or A-SKU, instrument render times, and scale only when concurrency demands it. Build RLS and token generation correctly from day one, because retrofitting security is far harder than scaling capacity.

If you want a clear, UK-led review of your embedding architecture, capacity sizing and security model before you ship, book a Trusted Numbers Review. We will tell you which pattern fits, what it should cost, and where the risks are, at a fixed, published fee that is credited against any follow-on build.