Report Page Tooltips in Power BI - How to Build Ones People Actually Read

Most Power BI reports have too many visuals on one page. Someone asks for detail, so a chart gets added, then a table, then a card, and by the third revision the page looks like a cockpit. Report page tooltips are one of the few features that push back against that. Instead of cramming supporting detail onto the canvas, you tuck it behind a hover, and it only appears when someone actually wants it. Done well, it keeps the main page clean and still answers the follow-up question the moment it comes up.

I want to walk through how report page tooltips work, where they genuinely improve a report, and the traps that turn them into a slow, confusing mess. Microsoft's documentation on report tooltips covers the setup steps. What I want to talk about is when to bother, because this is a feature people either ignore completely or overuse until the report crawls.

The two kinds of tooltip

There are two things people mean when they say "tooltip" in Power BI, and it helps to keep them separate.

The default tooltip is the little box that pops up when you hover over a bar or a point. It shows the values that feed that data point, and you can add extra fields to it in the visual's tooltip well. That is fine for quick numbers. Hover over a column, see the exact figure and maybe one or two supporting measures. No design work, no extra pages, it just happens.

The report page tooltip is the interesting one. You build an entire report page, size it small, mark it as a tooltip page, and then any visual can use that page as its hover content. So instead of a box with three numbers, hovering over a bar can show a mini chart, a trend line, a couple of cards, whatever you design. It is a small report that appears in context, filtered automatically to whatever the user is pointing at.

That automatic filtering is the part that makes it powerful and the part people trip over. When you hover over the "Queensland" bar, the tooltip page gets filtered to Queensland without you wiring anything up, as long as the fields line up. Get that wrong and the tooltip shows the grand total on every hover, which is worse than useless because it looks like it is working.

Setting one up without the usual pain

The mechanics are simple once you have done it once. You create a new page, open the page formatting options, set the page type to Tooltip, and set the page size to Tooltip as well so it is small enough to float over the canvas. Then you build your visuals on that tiny page as if it were a normal report, just smaller.

Back on your main visual, you go to the tooltip settings, switch the type to Report page, and pick your tooltip page. From then on, hovering triggers the page.

The bit worth getting right is the filtering. The tooltip page inherits the filter context of the data point being hovered, but only for fields the tooltip page actually knows about. If your bar chart is broken down by state and your tooltip page has a chart that also uses state, the cross-filter works and you see state-specific detail. If the tooltip page uses a field the main visual is not slicing by, that field will not be filtered by the hover, and you will get totals. A quick test: hover over two different bars and check the tooltip numbers change. If they are identical, your context is not flowing.

One practical Australian note, because it comes up. If your main visual shows something like revenue by region and your tooltip shows a month-by-month trend, make sure the date table and the region field are both in the model correctly and that the tooltip visuals are using the same fields. I have lost more time than I care to admit to a tooltip that "worked" but silently showed the same trend on every hover because the region relationship was inactive.

Where they earn their place

I like report page tooltips a lot in specific situations, and I will tell you the ones where they consistently pay off.

The best use is progressive detail. Your main page answers the headline question at a glance, sales by state, say, and the tooltip answers the obvious next question, how has that state trended over the last twelve months, without the user clicking anything or leaving the page. We built a sales dashboard for a distribution business where the executives wanted a clean single-page overview but the state managers wanted trend and product mix. The tooltip solved the argument. The exec page stayed clean, and hovering gave the managers their detail. Nobody had to build two reports.

They also shine when screen space is genuinely tight. On a page that is already full, a tooltip adds a whole extra dimension of information for zero canvas cost. That is a real win on reports that get viewed on smaller laptops in the field.

And they work well for context that is useful but not primary. Definitions, a small breakdown, a sparkline, a "same period last year" comparison. Things people occasionally want but should not have to look at all the time.

Where they fall down

Here is the honest side. Report page tooltips have a few failure modes that show up again and again.

The first is people who do not know the tooltip exists. A tooltip only helps if the user hovers, and plenty of business users do not think to hover, especially the ones who print reports or view them on a tablet where hover is awkward or impossible. If the information is important, it cannot live only in a tooltip. Hover is a convenience layer, not a place to hide anything that matters. I have seen a report where the only way to see the actual dollar figures was to hover, and half the audience never found them.

The second is performance. Every report page tooltip is a real report page with real queries, and those queries run on hover. If your tooltip has four visuals each hitting a big model, hovering around the main chart fires query after query, and on a heavy semantic model it gets laggy fast. A tooltip that takes two seconds to appear is a tooltip people stop using. Keep tooltip pages light. One or two visuals, simple measures, and test it on the real data volume rather than a tidy sample.

The third is mobile and touch. Tooltips and touchscreens do not mix. There is no hover on a phone, so a report that leans on tooltips for anything essential simply breaks for mobile users. If a chunk of your audience is on the Power BI mobile app, plan for the tooltip content to be reachable another way.

The fourth is overdesign. Because you can build a whole page, people build a whole page. Eight visuals, titles, a background image, and suddenly the "tooltip" is a second dashboard flapping around under the cursor. Restraint is the whole point. If the tooltip needs that much, it should be a drillthrough page you click into, not something that appears and disappears on hover.

My rule of thumb

Use report page tooltips for the useful-but-secondary detail that answers the next obvious question, keep them to one or two light visuals, and never put anything essential behind a hover. If the content is important enough that everyone needs to see it, put it on the page. If it is rich enough to warrant real exploration, make it a drillthrough. The tooltip lives in the middle: nice to have, quick to reach, quietly ignorable.

This is the kind of decision that separates a report people use from one that impresses in a demo and gets abandoned. Most of our Power BI consulting work is exactly this: not new visuals, but judgement about what goes where so the report answers questions at the speed people ask them. It sits inside the broader business intelligence work we do, where the aim is reports that drive decisions rather than dashboards that gather dust.

If you have got Power BI reports that are either too cluttered or hiding half the answer behind interactions nobody discovers, or you want reporting built by people who will tell you when a tooltip is the wrong home for something, have a look at our services or get in touch.