How do I embed an interactive chart in SharePoint?

The short answer is the Embed web part on a modern SharePoint page: edit the page, add Embed, paste your iframe code, publish. What takes the afternoon is not the paste. It is the four constraints Microsoft applies around it, one of which needs an administrator rather than a fix, and the sizing behaviour their documentation does not mention at all. This is the internal-wiki version of the same problem, so if your research is going into a team site rather than a marketing page, the governance is the part to plan for.

The Embed web part, and its two modes

On a modern page, click Edit, open the web part picker with the plus button, and choose Embed. The property panel accepts two different things. The first is a website address, which works for sources that publish a recognised embedding service. The second is embed code, the block of markup a chart tool gives you under a label like Embed or a code icon. For a self-hosted chart the second mode is the one you want, because it is the one that lets you control the frame.

It must be an iframe, not a script

Microsoft is explicit that embed code has to be iframe-based, starting and ending with iframe tags, and that code using script tags is not supported. This rules out a whole category of charting embeds. Plenty of libraries and dashboard tools hand you a small script snippet that injects the chart into the page, and none of those will run here. If that is what your tool gives you, the workaround is to host the chart on its own page at a public HTTPS URL and iframe that page instead. Confluence has an equivalent split, where script-based embeds need an admin-installed HTML macro, so the pattern will feel familiar if you have already been through the Confluence version.

HTTPS, with no exceptions

Only secure sites can be embedded, and the URL inside your iframe has to begin with https. A chart served from an internal box over plain http will fail, and so will a page that loads its data over http even if the page itself is secure. If you are pointing at an internal service, that means a certificate, not a firewall exception.

The allow-list is the real blocker

This is the SharePoint-specific catch and it stops more embeds than any syntax error. Site collection administrators control whether contributors can embed content from external sites and which domains are permitted. When a domain is not on that list, the web part refuses the embed and returns a message saying that embedding content from this website is not allowed. Nothing you change in the iframe will fix it, because the block is at tenant governance rather than in your markup. If you are shipping a recurring internal chart, get the domain allow-listed once at the start rather than debugging the same error every time the page is rebuilt. Worth knowing that not every external site permits being framed either, so a source can be secure, allow-listed and still refuse to load because it sets its own framing restrictions.

Sizing is your problem, not SharePoint's

Microsoft's own documentation for the web part says nothing about dimensions, and that silence is the warning. An iframe does not resize itself to fit its content, and SharePoint will not do it for you. Set an explicit height on the iframe, and if you want it to behave across screen widths, wrap it in a container with a percentage-based aspect ratio and give the iframe a width of 100 percent. Then check it in the section layout you actually use. A chart that reads well in a full-width section becomes unreadable in a one-third column, and the fix is usually to simplify the chart rather than to shrink the frame: fewer series, larger tick labels, no legend that wraps to three lines.

If the chart is a Power BI report, use the Power BI web part

SharePoint ships a dedicated Power BI web part that takes a report URL and renders it natively, and if your numbers already live in Power BI that is the better route: it respects the report's own permissions and needs no allow-listing. It is worth being straight about where it stops. It renders Power BI reports and nothing else, so a chart you built anywhere else, or one you want to publish to readers outside the tenant, still goes through the Embed web part. The two paths solve different problems and picking the wrong one costs a day.

Check the published page, and think about who can see the source

The editing surface is not the finished page. Publish, then open the page as a normal reader, ideally in a private window and on a phone, because embeds that look right in the editor can be blocked, clipped or scrolled awkwardly once live. One more thing that matters more on an internal site than a public one: SharePoint permissions control who can open the page, but they do not extend into the iframe. The chart is served by whatever host it lives on, so if that URL has no authentication in front of it, anyone holding the link can view the data whether or not they have access to the site. For anything sensitive, put the access control on the chart host, not on the SharePoint page.

Once a chart is an HTTPS page you control, the same embed travels: SharePoint here, Confluence for the wiki, Notion for working docs, WordPress when it goes public. Quadesto publishes each chart as its own HTTPS page with an iframe snippet, which is exactly the shape the Embed web part asks for. [QUADESTO-EMBED: quarterly performance dashboard, responsive iframe sized for a full-width SharePoint section]. The free tier embeds live with a Made with Quadesto credit; Pro at 149 pounds a month removes the attribution, adds unlimited seats and views, and lets you theme the chart to the house style your internal decks already use.