How do I embed an interactive chart in Google Sites?

Open your page in the new Google Sites, click Insert in the right-hand panel, choose Embed, and you get two tabs: By URL, which takes a link and renders whatever preview that link offers, and Embed code, which takes raw HTML for a real iframe. For an interactive chart you almost always want Embed code, because that is the tab that gives you control over the frame. Paste the iframe, click Insert, then drag the block to the size you want on the page. The two things that actually go wrong are not in that sequence: whether the person viewing your site can reach the chart, and the fact that the frame will never grow to fit its contents.

By URL or Embed code

By URL is the quicker path and it works when the destination publishes the metadata that lets other sites render a preview of it. What you get back is that provider's preview, not your chart at your dimensions, and if the provider offers no preview you get a link card. Embed code is the honest route for a chart: you supply the iframe, you set the height, and what renders is your page inside a frame on theirs.

Google's own documentation is specific about the code tab's rules: JavaScript has to sit inside script tags and CSS inside style tags. A bare snippet pasted without its wrapper silently does nothing, which is the first thing to check when a widget-style embed comes up blank. It also says plainly that some sites will not allow their content to be added at all, which is the polite description of a chart host that sends a frame-blocking header. If a URL loads perfectly in a browser tab and shows an empty box inside Sites, that is the header talking, and no amount of editing your snippet will change it.

The access trap that breaks internal dashboards

This is the Google Sites specific catch and it is worth more than everything else on this page. A Site is very often restricted to one Workspace domain, which is exactly why teams use it for internal research pages and board material. But restricting the Site does nothing to grant access to the things embedded in it. Google says it directly: if a file is stored on a shared drive or has restricted sharing permissions, only people with access will be able to see it, and you have to share access separately when you publish.

The failure mode is nasty because it is invisible to the author. You built the page, so you can see the chart, and every colleague who was in the room when it was built can see it too. The person who could not is the one who says nothing and assumes the section is still being written. Test it the only way that proves anything: open the published URL in a private window, or ask someone with the plainest possible permissions to load it, before you send the link round.

The rule that keeps you out of trouble is to decide, once, whether the chart is public with an unguessable URL or genuinely private behind the same login as the Site. Both are defensible. Mixing them, a private Site holding a chart nobody outside your own account can load, is the state that produces empty rectangles. The same question comes up on SharePoint and Confluence, and it has the same answer on all three.

Sizing, and the frame that will not grow

An embed block in Sites is a fixed rectangle you drag to size in the editor. The chart inside it does not tell the block how tall it wants to be, and the block does not ask, so a chart that reflows on a narrow screen will either be cut off or float in white space. Sites also lays pages out on its own grid, so the block that looks right on your laptop is a different shape on a phone.

Two practical fixes. Build the chart to fill whatever box it is given, with a width of 100 percent and a height of 100 percent, so the frame size becomes the only decision. Then set the block a little taller than looks necessary, because a scrollbar inside an embedded chart is worse than a strip of empty space beneath it. Check the published page at phone width before you call it done; the editor preview is not the same thing.

When a Google Sheets chart is the better answer

Sites has a native Sheets integration, and for a simple bar or line chart driven by a spreadsheet your team already maintains, it is the right tool. It updates with the sheet, it needs no third-party anything, and it inherits the permissions story you are already managing. Do not fight it for the sake of it.

The line worth knowing is where spreadsheet charting stops. A yield curve with a proper date axis, a volatility surface, a chart that has to state its own methodology beside the numbers, anything with a hover that shows more than the plotted value: those are not Sheets charts, and forcing them produces something that technically renders. That is the case for embedding a purpose-built chart instead, and it is the same judgment call whichever platform the page lives on.

One thing an embedded chart will not do is survive being forwarded. If the page gets summarized into an email, the iframe does not travel, and the answer there is the opposite of this one: freeze an image at send time and link out to the live version. That is covered in the guide to charts that survive Outlook and Gmail.

[QUADESTO-EMBED: responsive chart sized to 100 percent of its container, public share URL, shown inside a Google Sites Embed code block at desktop and phone widths]

Doing it with Quadesto

Quadesto gives every chart a share URL and an iframe snippet built to fill its container, which is what the Sites embed block needs, and it keeps the methodology note attached to the chart rather than in a caption someone has to retype. The free tier embeds live with a Made with Quadesto credit; Pro at 149 pounds a month removes the attribution and adds branded themes for an internal research page.