A complete guide to the four methods for embedding Tableau dashboards in websites, with a decision framework for choosing the right approach.
Embedding a Tableau dashboard means displaying a Tableau view (hosted in Tableau Cloud or Tableau Server) inside another digital experience - a marketing site, a customer portal, an internal intranet, or a SaaS product. To the end user, it feels like the dashboard "lives" in your app: they can filter, click, drill, and interact without opening Tableau in a separate tab. Tableau supports this directly via generated embed code and, for more advanced use cases, via a modern JavaScript embedding library (Embedding API v3) built around web components.
But "getting a dashboard to appear on a page" is the easy part.
Most embedding efforts struggle when teams try to move from a working demo to a secure, branded, production-ready analytics experience that can support real users, permissions, and long-term maintenance. Tableau's own documentation hints at this split: basic embedding can be as simple as copy/paste, while more advanced embedding introduces authentication patterns, API versions, and application integration choices.
Before picking a method, it helps to name the problems that show up in every real embed (especially for external audiences):
Are users signing in with Tableau credentials, or your app's login? If you want seamless sign-in, Tableau Connected Apps establish a trust relationship between your app and Tableau.
If you serve dashboards to multiple customers/clients, preventing data leakage across tenants is non-negotiable. This is usually where "we'll just embed it" turns into a real security architecture conversation (user identity, attributes/claims, entitlement logic).
Does the embedded experience look native to your app, or like a third-party widget? Small details - toolbar behavior, nav, loading states, mobile layout - shape whether users trust and adopt it.
Tableau licensing commonly comes up as role-based/user-based vs usage-based models, and the wrong choice can balloon cost as external usage grows. Tableau documents both license model concepts, and also promotes usage-based licensing for embedded analytics scale with larger, infrequent users.
Even when Tableau dashboards are designed for device layouts, embedded containers (iframes, constrained CMS areas, app panels) can create awkward scrolling, clipped tooltips, and usability issues.
API versions, browser changes, Tableau upgrades, SSO/IdP updates, and security review requirements aren't "one-time." Tableau explicitly notes compatibility constraints (e.g., Embedding API v3 requires Tableau 2021.4+ for embedded views).
With that framing, here are the four most common embedding approaches - along with how each approach is uniquely different with their own pros and cons.
An iframe is the shortest path from "dashboard exists" to "dashboard visible on my webpage." This method works because Tableau can generate a view URL (or embed code) that you place inside an HTML iframe element. Tableau's own guidance shows this as a valid approach when you can't (or don't want to) use JavaScript embedding.
The key tradeoff: iframes are display-first. They're great at showing content, but limited at feeling like a cohesive application component (identity, deep UI integration, event handling, complex workflows).
Open the published view on Tableau Cloud/Server, click Share, then copy the embed code (or link) Tableau provides and paste it into your HTML.
Internal dashboards where users already authenticate normally (or the view is otherwise accessible). Proofs of concept where the goal is "validate the dashboard content," not "ship a full analytics product." Simple webpages where you have minimal engineering support.
Limited application control (events, filter syncing, custom UI flows). Authentication and data isolation are not solved "by iframe" - you still need a real security approach behind it. Branding and UX often feel bolted-on (toolbars, spacing, responsiveness, loading states).
Tableau's Embedding API v3 is the "real" embedding toolkit when you want dashboards to behave like first-class UI components in a web app. It's designed for integration: controlling filters, responding to events, and building richer user experiences around Tableau content using web components like <tableau-viz>.
This is also where the conversation becomes less about "embedding" and more about application architecture: identity flows, token issuance, claims, entitlements, and ongoing version management.
Your app loads the Embedding API library and renders the viz as a web component. For secure embedding, you typically authenticate through Connected Apps and provide a JWT-based trust flow. Tableau's embedding authentication docs describe using a JWT and configuring scopes/claims appropriately.
SaaS products or portals where Tableau must blend into your UI and workflows. Deep interactivity (programmatically set filters, react to marks selection, drive navigation). Cases where "embedded analytics" is part of the product experience - not an afterthought.
This becomes a software project: front-end, back-end, auth, security review, hosting, observability. Teams often underestimate the non-Tableau work: user provisioning strategy, token lifecycle, entitlement mapping, incident response readiness. You own long-term maintenance: upgrades, breaking changes, IdP adjustments, and integration testing.
CMS-based embedding (WordPress, SharePoint, Confluence, etc.) exists because many organizations want analytics where work already happens - knowledge bases, intranets, team hubs - without building a custom app.
In practice, many CMS "Tableau embedding" options are wrappers around a basic embed (often an iframe-like approach), which is why they can be easy to launch but hard to productionize for external client use.
Install a plugin or use a web part (unique to each platform), configure the Tableau view/source, and place dashboards on CMS pages.
Internal enablement: "put dashboards next to documentation, SOPs, and team content." Organizations that have standardized on a single CMS and want fast adoption with low change management.
Typically limited control compared to full Embedding API patterns. Branding and UX constrained by the CMS container and theming system. Rarely a great fit for external customer portals where you need tenant isolation, tailored navigation, and a product-grade feel.
A portal product is a dedicated application layer that sits between your external users and Tableau. Conceptually, it exists to solve the real-world gap: Tableau can render beautiful analytics, but your organization still needs an app experience to manage users, access, branding, navigation, and lifecycle operations.
This approach is especially compelling when your dashboard audience is external (customers, partners, franchisees, vendors) and you don't want embedding to turn into a multi-quarter engineering initiative.
You connect the portal to Tableau (Cloud or Server), configure branding/navigation, define how users authenticate, and map users to what they're allowed to see. The portal becomes the consistent surface area for external analytics experiences (sign-in, landing pages, client segmentation, and support workflows).
External-facing analytics where security and tenant isolation are core requirements. Organizations that want a production-grade experience in days/weeks, not months. Teams that prefer to avoid long-term embedding maintenance overhead.
Less "infinite flexibility" than building your own bespoke app (though many portals cover 90% of common needs). You're introducing an additional system/vendor, which means you should evaluate admin controls, auditability, and roadmap alignment.
A practical way to choose is to answer two questions:
Internal only: Start simple. If the goal is access and adoption inside the org, generated embed code/CMS embedding can be enough.
External users: Treat this like a product. Assume authentication, tenant isolation, and cost predictability will matter immediately.
Strong dev team + product requirements: Embedding API v3 is the "power tool," and Tableau provides both official docs and sample code to support it.
Limited dev capacity or desire to ship fast: A portal product can reduce time-to-production and reduce maintenance burden, especially as auth and security requirements expand.
And keep licensing in view early: Tableau distinguishes license model concepts (role-based vs usage-based), and both have scaling considerations that benefit from a partner that has gone through multiple external-facing deployments.
Portal Panda gives your external clients a secure, white-labeled interface to access Tableau dashboards — with zero custom code.
Book a Demo