How to embed Power BI in a website: public, secure and Embedded options, costs and the security catch

The short answer

Power BI gives you three kinds of embed, and the right one depends on who should see the report. Publish to web makes an iframe anyone can open without signing in, with nothing to pay per viewer, but Microsoft warns that anyone can then reach the data in the report's model: it is for public data only.

Secure embed and the SharePoint Online web part keep the report private: viewers sign in, and each needs Power BI Pro (USD 14 a user a month, paid yearly) or Premium Per User (USD 24), unless the content sits on a Fabric F64 or larger capacity. Embed for your customers, usually called Power BI Embedded, shows reports to people without a Power BI account, but production needs a capacity running all month: from USD 262.80 a month for a Fabric F2, or USD 735.91 for an A1, pay-as-you-go in East US, on Microsoft's pricing pages read on 22 October 2026.

For internal reporting, a Power BI report behind a sign-in is usually the right tool. For a public page that has to load fast, carry your brand, work on phones, be accessible and be readable as text, a chart built into the page often does the job better and costs less to keep online.

Every way to put a Power BI report on a website, compared

Publish to web: public, free to view, no sign-in

Publish to web turns a report into a link and an iframe you paste into a page. Viewers don't need to be Power BI users and don't sign in. Microsoft's prerequisites:

• A Power BI license to publish from My workspace, and Pro or Premium Per User to publish from any other workspace.
• Edit permission on the semantic model and reshare permission on the report. It isn't available for reports shared with you.
• Your Power BI administrator has to enable the Publish to web tenant setting.

In the report, choose File > Embed report > Publish to web (public), confirm Microsoft's warning, and copy the link or the HTML. You can set the size, the default page and a placeholder image, which Microsoft says makes the web page load faster. Each report gets one embed code.

What Publish to web can't publish

Microsoft lists the reports it doesn't support. The ones that most often stop a website project:

• Reports that use row-level security.
• DirectQuery and Live Connection sources, including Analysis Services. Import or composite mode works.
• Shared or certified semantic models, and models stored in a different workspace from the report.
• R and Python visuals, paginated reports, mobile layout views and multiple-language reports.
• Exporting data from the published visuals.

Refresh, traffic and revoking a code

Changes to the report show up in the embed on their own, but Microsoft caches the data for one hour and doesn't recommend Publish to web for data that has to refresh often. If a report gets too many queries in a short time, viewers can't open it until the heavy usage passes. You manage codes in the workspace's Settings > Manage embed codes, and deleting a code disables every link and iframe that uses it. The person who created the code has to keep access to the report, with the license its workspace requires, or the embed stops working.

The security catch with Publish to web

Microsoft's warning on the Publish to web page is blunt. Anyone on the internet can view the report, with no authentication, including detail-level data the report aggregates, and "anyone can access the underlying data in your model" even when the report doesn't display it. In practice:

• Publish only data you'd post as a spreadsheet. If the model holds customer rows, salaries or anything confidential, hiding a column from the visuals doesn't protect it.
• Row-level security can't help. Reports that use it aren't supported.
• Expect the link to travel. Microsoft says viewers can easily share the report on social media.
• There is no password option. Viewing requires no authentication. If people must sign in, use one of the methods below.
• URL filters aren't security either. Microsoft's secure embed page notes that viewers can change or remove URL parameters.
• Review the codes. Microsoft's tenant settings guide tells admins to review embed codes regularly and remove any with private or confidential content.

Why Publish to web is missing or greyed out

If you can't find the option, Microsoft's documentation points to these causes:

• The tenant setting is off, or you aren't in an allowed group. Then the option isn't visible. An admin turns it on in the admin portal under Tenant settings > Export and sharing settings > Publish to web, for the whole organization or for specific security groups.
• New codes need approval. Admins can choose "Allow only existing embed codes", and then you have to ask them to allow yours.
• The report isn't yours to publish. Reports shared with you directly or through an app, and workspaces where you can't edit, don't qualify.
• Private links are on. When admins block public internet access with private links, Publish to web is greyed out for the whole tenant.
• The content is on Power BI Embedded capacity. Microsoft's Power BI Embedded FAQ says that content can't be shared through publish to web.

Secure embed and SharePoint: for people who sign in

Secure embed (File > Embed report > Website or portal) gives you a link or an iframe for any portal that accepts one. Item permissions and row-level security apply, and only signed-in users with view permission see the report. Each viewer needs Pro or Premium Per User, unless both the report and its semantic model are on Fabric F64 or larger, or Power BI Premium capacity. Viewers sign in again in every new browser window or tab, the host page has to use HTTPS, and the option isn't available for Azure B2B guest accounts.

On the page as updated on 24 September 2026, Microsoft adds that because of Chromium security updates, secure embed "no longer works exactly as it used to" and users may have to sign in more than once. It suggests building your own Power BI Embedded solution instead.

The SharePoint Online web part does the same inside modern SharePoint pages, and it's the option Microsoft points to for single sign-on. The person embedding needs Pro or Premium Per User, and viewers need access to both the page and the report. Free users can view only when the content is on F64 or larger, or Premium.

Power BI Embedded: your site, your login

Power BI embedded analytics has two scenarios, and developers build both:

• Embed for your customers (app owns data). Your app authenticates to Power BI with a service principal, the method Microsoft recommends, or a "master user" account. Your users don't sign in to Power BI and don't need a license; your site handles any login itself. Besides Publish to web, it's the embed Microsoft offers for people without a Power BI account. It takes a Microsoft Entra app registration, embed tokens generated by your server and Microsoft's JavaScript client.
• Embed for your organization (user owns data). People sign in with their Microsoft Entra accounts. Microsoft lists three production setups: every user on Pro, every user on Premium Per User, or a capacity of F64 or larger.

Embed for your customers needs a capacity in production. You can develop with free embed trial tokens on a Pro license, but the report shows a "Free trial version" banner until a capacity is bought.

A SKUs, F SKUs and the end of P SKUs

Microsoft's capacity guide lists three offers: Power BI Embedded in Azure (A SKUs), Microsoft Fabric in Azure (F SKUs) and Power BI Premium through Microsoft 365 (P and EM SKUs). All of them run embed for your customers. What matters when you choose:

• Only P capacities and F64 or larger let users with free licenses view content in secure embed, SharePoint and embed for your organization. Below F64, and on every A SKU, each viewer needs Pro or Premium Per User. Secure embed doesn't run on A SKUs at all.
• Microsoft is retiring P SKUs at the end of each customer's agreement term and no longer sells new ones, according to its migration guide (updated 22 July 2026), and its Fabric licensing page calls F SKUs the recommended capacities. For a new purchase, the choice is between A and F.
• A and F capacities are billed by usage with no commitment, unless you reserve, and can be paused. But Microsoft's Power BI Embedded pricing FAQ says embedded content doesn't load while the service is paused, so a report on a public site needs its capacity running every hour of the month.

What each option costs

These are list prices in USD, read on 22 October 2026 on Microsoft's Power BI pricing page, its Power BI Embedded pricing page and its Microsoft Fabric pricing page, for Azure's East US region. Azure prices vary by region and currency, and Microsoft notes its Power BI prices may differ at checkout. Monthly figures are Microsoft's, for a capacity running all month.

Microsoft says a one- or three-year Fabric reservation saves about 41% against pay-as-you-go. Region matters: the same F2 costs USD 408.80 a month pay-as-you-go in Brazil South.

None of these prices include designing or building the report. That work is separate, whoever does it.

When a custom web chart is the better choice

For internal reporting, Power BI is usually the better tool: people filter and drill down on their own, row-level security decides who sees what, and your team already knows it. A chart built with code into the page earns its cost when the audience is public or external and the chart is part of your website or product. In particular, when it has to:

• Load fast. Microsoft itself suggests a placeholder image so the page loads faster, and a busy public report can hit the heavy-usage state. A chart built into the page ships with it and is measured with the rest of your Core Web Vitals.
• Carry your brand. A Publish to web embed brings Power BI's frame: Microsoft suggests adding 56 pixels to the iframe for its bottom bar and shows gray letterboxing when sizes don't match. Embed for your customers can be branded as your own, at capacity prices.
• Work on phones. Publish to web doesn't support mobile layout views. A custom chart decides which labels and comparisons survive on a small screen.
• Speak more than one language. Publish to web doesn't support multiple-language reports, which matters on a bilingual website.
• Be accessible to everyone who lands on it. Power BI has real accessibility features, from keyboard navigation and alt text to Show data, an HTML table a screen reader opens with Alt+Shift+F11, and Microsoft says a report should be treated "more like an application and less like a document". WCAG's guidance on non-text content describes a chart with a short label, a longer description of its trends and, where practical, the data in a table; non-text contrast asks for 3:1 contrast on the parts of a graphic needed to understand it, such as each line in a graph. On your own page, the summary and the table can sit next to the chart for every reader. Our WCAG 2.2 checklist covers the rest.
• Be readable as text. When the numbers and the explanation are text in your page's HTML, anyone reading the page, including search engines and AI assistants, gets them without running a report.
• Tell a story. A data story walks the reader through a sequence, such as the place, then the trend, then the detail, before it opens up filters.

The cost works differently too. A capacity is a bill every month the report stays online; a custom chart costs design and development up front, then runs as part of the site. Data that changes monthly or quarterly can ship as static files: Cloudflare, for example, states that requests to static assets on Workers are free and unlimited. Live data needs an API and someone responsible for updates, so compare the whole cost.

Most data visualization tools for websites are open-source libraries with no per-viewer fee: D3 and Observable Plot (ISC-style licenses), Vega-Lite (BSD 3-clause), Apache ECharts (Apache 2.0) and Chart.js (MIT). Many teams use both: staff keep working in Power BI, and the public sees a curated chart built from an export of the same model.

Which option to choose

What to do next

1. Decide whether the data could be published as a spreadsheet. If not, rule out Publish to web.
2. Count your viewers and note who they are: staff with Microsoft accounts, customers or the public.
3. Price the options with the tables above, in your Azure region.
4. Ask your Power BI administrator about the Publish to web and embedding settings before you promise a public embed.

If the chart belongs on a public page or inside a product, Dardo's data visualization service designs and builds either route, a Power BI dashboard or a custom web interface like our Shiimain prototype.