Power BI's standard visual library is extensive and well-optimised for analytical accuracy. Where it falls short is visual design flexibility — the degree to which a report author can depart from the default visual styling to produce a dashboard that matches a client's brand system, achieves a specific layout requirement, or renders a KPI card design that simply looks better than the out-of-the-box card visual allows. For most teams, the options are: accept the design constraints of standard visuals, purchase and learn a custom visual, or commission bespoke custom visual development. The Power BI HTML CONTENT visual specifically the HTML CONTENT (LITE) edition — offers a fourth path: write the visual as HTML directly within a DAX measure, generating any layout or design that HTML and CSS can express, driven by live model data.

The Design Gap in Standard Power BI Visuals

The design constraints of Power BI's built-in visuals are a direct consequence of their architecture. Each standard visual is a self-contained rendering component with a defined set of configurable properties — colours, fonts, padding, borders, data labels. Those properties cover the majority of standard reporting use cases well. They do not cover the scenarios where a report needs to look genuinely different: a branded executive dashboard with a client's exact colour palette, a KPI card with a specific layout of metric, comparison, trend indicator, and narrative text, or a header panel with a logo, report title, and navigation controls rendered at pixel-level precision.

Report authors working without HTML capabilities handle this limitation through a combination of carefully layered visuals, background images exported from Figma or PowerPoint, and bookmarks — an approach that works but creates maintenance fragility and limits the degree to which live data can drive visual presentation. The HTML CONTENT visual replaces that fragile layering with a single, data-driven HTML component that renders exactly what the DAX measure produces.

"With HTML CONTENT and an AI assistant, the design brief becomes the code brief. Describe the KPI card you want — the layout, the colours, the conditional logic — and get working HTML back in seconds. The Power BI developer becomes a design director, not a CSS author."

What the HTML CONTENT (LITE) Visual Is

HTML CONTENT (LITE) is a certified custom visual available from the Microsoft AppSource marketplace, developed by BI Samurai. It renders a Power BI measure that returns an HTML string as a fully rendered HTML document within the visual's canvas area. Any valid HTML and inline CSS that fits within the visual's dimensions is rendered — text, tables, grids, flex layouts, conditional styling, embedded SVG icons, progress bars, and more.

The LITE edition is the free tier of the HTML CONTENT visual, with certain feature restrictions compared to the paid Pro edition — notably the absence of JavaScript execution and some advanced layout capabilities. For the vast majority of dashboard component use cases — KPI cards, styled metric tiles, header panels, progress indicators, data tables with custom row styling — the LITE edition is fully sufficient and carries no per-report licensing cost beyond the standard Power BI setup.

The visual is certified by Microsoft, which means it passes AppSource security review and is available in Power BI Service environments where tenant administrators have restricted the use of uncertified custom visuals. This certification is an important practical consideration for enterprise environments with strict custom visual policies.

How HTML CONTENT Works: DAX Measures as HTML Strings

The fundamental mechanism of the Power BI HTML CONTENT visual is that a DAX measure returns a text string containing valid HTML, and the visual renders that string as a document. The DAX measure uses standard string concatenation, conditional expressions, and FORMAT function calls to embed live data values, conditional colours, and computed layout elements into the HTML template.

A simple example: a KPI card measure that displays the current period's revenue with a green or red colour depending on whether it is above or below target uses a DAX pattern like the following — a CONCATENATE-based construction that combines static HTML template strings with computed data values and a conditional colour expression.

Revenue KPI Card HTML =
VAR _Revenue = [Total Revenue]
VAR _Target = [Revenue Target]
VAR _Var = DIVIDE(_Revenue - _Target, _Target)
VAR _Color = IF(_Revenue >= _Target, "#22c55e", "#ef4444")
VAR _Arrow = IF(_Revenue >= _Target, "▲", "▼")
RETURN
"<div style='font-family:Sora,sans-serif;padding:20px;
             background:#1A2356;border-radius:8px;'>
  <div style='font-size:11px;font-weight:700;letter-spacing:.15em;
              text-transform:uppercase;color:rgba(255,255,255,.5);
              margin-bottom:8px;'>REVENUE</div>
  <div style='font-size:32px;font-weight:800;color:#ffffff;
              margin-bottom:6px;'>"
  & FORMAT(_Revenue, "$#,##0.0,,") & "M</div>
  <div style='font-size:13px;font-weight:500;color:" & _Color & ";'>"
  & _Arrow & " " & FORMAT(_Var, "0.0%") & " vs Target</div>
</div>"

The key authoring consideration is that the DAX measure must return a single text value — the complete HTML string. All conditional logic, formatting, and data binding must be expressed within the DAX expression before the HTML string is assembled. This means that dynamic conditional styling (changing a card's border colour based on a variance threshold, for instance) is handled as a DAX IF or SWITCH expression that resolves to the appropriate CSS colour value before being embedded in the style attribute.

The Claude AI Workflow: Generating HTML from a Design Brief

Writing the HTML template component of a DAX HTML CONTENT measure by hand — especially for complex multi-element layouts — is time-consuming and requires CSS fluency that not every Power BI developer has. The Claude AI workflow that Numlytics uses replaces this with a conversation-based generation process: describe the visual component you want, specify the data values it should contain and how they should behave conditionally, and Claude generates the HTML and CSS template that the developer then wraps in a DAX concatenation expression.

A typical prompt to Claude for a KPI card component might be: "Generate an HTML card for a Power BI HTML CONTENT visual. The card should be 280px wide, have a dark navy background (#1A2356), show a metric label in uppercase small caps, a large formatted number as the primary value, and a green or red delta indicator with an arrow. All styling must be inline CSS — no external stylesheets or JavaScript. Return only the HTML."

Claude returns a complete, valid HTML snippet with inline CSS that the developer can immediately embed into a DAX string concatenation. The developer replaces the static placeholder values in the HTML with DAX variable references, adds the conditional colour logic as DAX IF expressions, and the measure is complete. A KPI card that would take 30–45 minutes of CSS authoring takes 3–5 minutes with this workflow — and the output is typically higher quality than what a developer without strong design instincts would produce manually.

Building Dynamic KPI Cards With Conditional Formatting

KPI cards are the most common HTML CONTENT use case because the built-in Power BI card visual — while substantially improved by the New Card visual in recent releases — still constrains the layout to a defined structure. HTML CONTENT cards can implement any layout: side-by-side metric and comparison, stacked metric with sparkline-style trend bar below, card with an icon determined by the metric category, or a card with a conditional background colour that changes the entire card appearance when a threshold is breached.

The conditional background pattern is particularly effective for executive dashboards where the goal is to draw the eye immediately to out-of-SLA or below-target metrics. Standard Power BI conditional formatting changes individual element properties — font colour, background colour of a specific cell. HTML CONTENT allows the entire card structure to change: a white card becoming a red-tinted warning card when a KPI breaches its threshold, with an additional text element appearing (styled as a warning label) that does not appear in the normal state.

Layout Components: Headers, Dividers, and Navigation Panels

Beyond KPI cards, HTML CONTENT is valuable for the structural elements of a dashboard that standard Power BI visuals handle poorly. Report headers — with a logo, report title, last-refresh timestamp pulled from a DAX measure, and a subtitle — are typically implemented as static background images in Power BI, which means the last-refresh timestamp cannot be dynamic. An HTML CONTENT header visual renders these elements from DAX, so the timestamp updates automatically with each dataset refresh.

Navigation panels — a vertical or horizontal list of report pages with the current page highlighted — can be implemented as HTML CONTENT visuals using DAX measures that return the current page context. Section dividers with styled horizontal rules, category labels with icon indicators, and progress bars showing completion percentages against targets are all layout components that HTML CONTENT handles naturally and that the standard visual library cannot produce.

Binding Live Data to HTML Templates via DAX

The data binding pattern for HTML CONTENT is the same regardless of the component type: define DAX variables for all data values needed by the visual, compute any derived values (percentage variances, conditional flags, formatted strings), and then assemble the HTML string with those variable values embedded at the appropriate positions.

One practical consideration is HTML entity encoding. Data values that contain characters with special meaning in HTML — ampersands, angle brackets, quotation marks — must be escaped or handled carefully to prevent the HTML renderer from misinterpreting them as markup. For most numerical and text measures in a Power BI model this is not an issue, but measures that return strings containing customer names, product descriptions, or other free-text fields require a sanitisation step in the DAX measure before embedding in HTML.

Governance Considerations for HTML CONTENT Visuals

HTML CONTENT visuals introduce a governance consideration that standard visuals do not: the visual's output is HTML code contained within a DAX measure, which means it lives in the semantic model alongside the analytical measures but serves a presentational rather than an analytical purpose. Enterprise BI governance programmes should establish clear conventions for how HTML CONTENT measures are named, where they are stored in the model's display folder structure, and how they are documented — distinguishing them from analytical measures during model review and certification processes.

The LITE edition's restriction on JavaScript execution is the primary security boundary: since HTML CONTENT LITE cannot execute JavaScript, it cannot make network calls, access browser APIs, or interact with the user's session outside the visual's canvas. This makes it significantly safer from a security perspective than a full custom visual that executes arbitrary JavaScript. For enterprise environments with strict AppSource custom visual policies, confirming that HTML CONTENT LITE is on the approved visual list before adopting it widely is the appropriate governance step.

HTML CONTENT vs Standard Visuals: Decision Guide

Next Steps for HTML-Enhanced Dashboard Design

The practical starting point for teams new to the Power BI HTML CONTENT visual is a single KPI card on an existing report page — replacing one standard card visual with an HTML CONTENT equivalent that matches the organisation's brand colours and typography. This controlled starting point validates the workflow (AppSource installation, measure authoring, Claude AI HTML generation) in a low-risk context before the approach is applied to a full dashboard redesign.

Once the basic KPI card pattern is established, the next components that deliver the most visual impact are the report header and any multi-metric summary tiles where the standard card visual's layout constraints are most visible. The combination of a dynamic HTML header, branded HTML KPI cards, and standard analytical chart visuals creates the layered visual quality that distinguishes a premium Power BI dashboard from a standard implementation — without custom visual development costs or specialist CSS expertise in the team.

If your organisation is building a new Power BI reporting programme or redesigning an existing dashboard estate with a quality-first approach, speak with a certified Power BI designer at Numlytics. We work with analytics and operations teams across the US, UK, Australia, and UAE to build Power BI dashboards that look as good as they perform — combining governed semantic models, HTML CONTENT components, and standard analytical visuals into coherent, brand-consistent reporting experiences. For the broader visual design context, see our posts on the Power BI New Card Visual and SVG use cases in Power BI reports.