How to Publish Interactive Visualizations on a Website

Choose a publishing model before you build

An interactive visualization can reach a website in three common ways: a hosted link, an embed, or code deployed directly in the site. The best choice depends on ownership and maintenance.

A hosted link is simplest. The visualization has its own stable page and can be shared independently. An embed places the interactive inside an article, report, or product page while the visualization platform continues to host it. Direct deployment gives the website team maximum control but also makes it responsible for dependencies, security policy, releases, and data updates.

Decide early because the destination affects width, navigation, typography, analytics, and content-security rules. A visualization designed as a full page may not work inside a 640-pixel article column, and an embed that assumes unrestricted scripts may fail in a locked-down CMS.

Give the visualization one stable public URL

Even when most people will see the visualization in an embed, give it one stable public URL—the canonical page. Put the title, summary, source, and a plain-language description there so a person can understand what the page is about even before the interactive loads.

A stable canonical page provides:

• a reliable link for citations and social sharing;
• a fallback when an embed is blocked;
• a place for methodology and source notes;
• a consistent identity across multiple embeds;
• a URL that can survive redesigns of the host article.

Avoid publishing only an opaque runner URL with no descriptive text. The surrounding page is part of the analytical product.

Make the embed fit the page it lives on

An embed needs an explicit sizing plan. A fixed-height iframe can clip controls on a phone and leave a large blank hole on desktop. Let the embed respond to the space it gets, and when the platform supports it, let the visualization safely tell the parent page how tall it needs to be.

Test the real host page, not only a standalone preview. CMS styles may alter margins, font sizing, overflow, or focus outlines. Sticky headers can cover tooltips. Cookie banners can reduce the usable viewport. A narrow article template may apply a maximum width that differs from the main site.

If the visualization has menus or modal panels, verify that they remain inside the embed boundary. Provide an “Open full screen” or “View interactive” link for readers who need more space.

Send the browser only the data the visualization needs

A published interactive should not carry a general-purpose copy of your source data. Prepare a small viewing dataset with only the rows, columns, and aggregations the experience needs. This improves privacy and usually makes the live visualization faster.

Aggregate where individual records are unnecessary. Remove credentials, internal IDs, notes, and sensitive attributes. Apply suppression rules before the data reaches the visualization. When a public page queries a live database, expose a controlled query result rather than a general-purpose connection.

Inspect the browser’s network requests and page source as part of the release review. Assume a determined reader can retrieve any data delivered to the client.

Make the noninteractive meaning available

JavaScript can fail because of network policy, browser extensions, corporate filters, or an application error. The page should still explain what the visualization covers and what the principal finding is. Include a textual summary and a source link outside the interactive frame when possible.

For accessibility, provide keyboard-operable controls, visible focus, and alternatives to hover. Complex visualizations should include a table, downloadable data, or structured summary. Use an informative iframe title such as “Interactive map of county election results,” not “Embedded content.”

If animation communicates a change, provide controls and respect reduced-motion preferences. Do not autoplay essential information faster than a reader can inspect it.

Check security rules and outside dependencies before launch

Many production sites use a Content Security Policy, or CSP, to control what browser code is allowed to load. Before launch, list the scripts, styles, images, fonts, frames, and network connections the visualization needs. Pin library versions and avoid adding unnecessary third-party dependencies.

An iframe can provide useful isolation, but its sandbox settings matter. Grant only the capabilities the visualization requires. If downloads, popups, forms, or same-origin access are unnecessary, do not enable them. Test links inside the visualization so they cannot unexpectedly navigate the parent page.

For direct deployment, generate a dependency inventory and verify license obligations. Keep secrets on the server; an API key placed in browser JavaScript is public.

Give the page enough text to stand on its own

A canvas or iframe cannot explain the whole page by itself. Give the host page a clear HTML title, meta description, canonical URL, useful social preview metadata, and structured data where it genuinely fits. More importantly, put ordinary text on the page that tells a person what they are looking at.

Use ordinary headings and text to explain:

• the question the visualization answers;
• the population, geography, and period;
• the measure and units;
• the data source and update date;
• the interaction readers can use;
• the central finding and important caveat.

This content improves discoverability without turning the page into keyword filler. It also makes the work easier for people to cite accurately.

Decide how updates propagate

A static export must be replaced wherever it appears. A hosted embed can update every placement when the source visualization changes, which is useful but creates responsibility: a revision may alter the meaning of an older article.

Separate three types of update:

1. Data refresh: new rows or values under the same definitions.
2. Methodology change: a revised measure, denominator, or source.
3. Design change: layout, wording, interaction, or accessibility improvement.

Record methodology changes prominently. Consider preserving a dated version for publications that must remain historically reproducible. Use version history and a rollback path for design releases.

Measure behavior without compromising readers

Basic usage data can show whether the visualization loads, which controls are used, and where errors occur. Define the questions before adding tracking. Do not collect sensitive filter selections or individual-level data simply because the interface makes it possible.

Track meaningful events such as opening a detail panel, changing a major comparison, downloading data, or following a source link. Distinguish an embed view from a real interaction. Respect the privacy policy and consent requirements of the host site.

Operational monitoring matters too: log refresh failures, JavaScript exceptions, slow requests, and missing assets. A public interactive should not depend on someone noticing that it looks blank.

Publish from Rhubarb

Rhubarb keeps analysis, visualization, and publication in one workflow. You can upload or connect data, ask the assistant to analyze and visualize it, inspect the relevant data-source SQL and visualization code, and publish the result without moving the project into a separate hosting stack.

Rhubarb can host the visualization while you place it inside your own site, including a paywalled or authenticated experience. That lets a publisher or membership organization keep the interactive hosted and maintained in Rhubarb while access to the surrounding content is controlled by its own product. Use a publication-specific data source and test access exactly as a real reader will see it.

Performance is part of this model too. A Rhubarb visualization can be backed by a narrow query that sends only the data needed for that view instead of carrying a broad analytical dataset into the live page. For public-facing interactives, that focus can make the viewing experience feel much lighter and faster.

Release checklist

Confirm the canonical URL, page title, description, source, last-updated date, privacy review, browser data payload, iframe title, keyboard behavior, touch behavior, small-screen layout, fallback text, content-security requirements, library versions, analytics policy, refresh owner, and rollback path. A visualization is publishable when the whole delivery system is understandable—not merely when the chart renders in the editor.

Frequently asked questions

Is an iframe the best way to publish an interactive chart?

An iframe is often the simplest isolated embed, but it needs responsive sizing, an informative title, host-page testing, and a plain link to the canonical visualization page.

Is data hidden in a visualization private?

No. Any data delivered to the browser can generally be inspected. Aggregate, suppress, and remove fields before publication rather than relying on visual hiding.

What should remain visible if JavaScript fails?

The host page should still provide the subject, principal finding, source, period, and a link or alternative table so the publication retains meaning.