Every few months someone on a design team posts the same chart-crimes thread, and the radar chart gets dragged out first. Too many overlapping shapes, misleading area, "just use a table." The criticism isn't wrong, exactly — it's just aimed at the wrong 80% of cases and misses the 20% where a radar chart is doing something a table structurally can't.

I've built both versions of the same slide more times than I'd like to admit, usually because a client insisted on the radar chart and I wanted to prove them wrong. About a third of the time, I couldn't.

What the shape is actually doing

A table is a lookup structure. You scan a row, find a column, read a number. That's its entire job, and it does it well — right up until the question stops being "what's the value" and becomes "what's the pattern." A radar chart trades precision for silhouette: five or six axes turn a set of scores into a polygon, and a polygon has a shape you recognize before you've consciously read a single number.

That's the actual advantage, and it's narrower than most explanations make it sound. It's not that radar charts are "more visual" or "more engaging" — it's that shape recognition is a different cognitive task than value lookup, and some questions genuinely live in the first category. Is this candidate lopsided or well-rounded? A table answers that only after the reader does the mental math themselves. A radar chart answers it before they've finished looking.

Where the table quietly wins — and doesn't announce it

Here's the part that gets skipped in most "when to use each chart" roundups: the table doesn't lose ground gradually as complexity increases. It loses it in one direction and gains it in the opposite one, almost immediately.

The moment someone needs an exact figure — a budget line, a compliance threshold, a score they'll quote in a follow-up email — the radar chart becomes actively worse than useless, because it invites a guess dressed up as a reading. Nobody eyeballs a polygon vertex and gets 7.3 out of 10 right. If your stakeholders are going to ask "wait, what was the actual number for reliability," you've picked the wrong chart no matter how good the shape looks.

The axis-count problem nobody flags until the deck is already built

Somewhere around eight or nine axes, radar charts stop clarifying and start decorating. Below that, roughly five to eight, the format tends to stay legible for a general audience — a threshold that shows up consistently enough across chart-design guidance (Highcharts' visualization team and the data-viz blog Antichaos both land on it independently) that it's worth treating as a soft rule rather than a style opinion.

What nobody warns you about is that the failure isn't gradual. A seven-axis radar chart with two overlapping entities reads fine. Add a third entity, or two more axes, and the whole thing crosses from "pattern" to "tangle" in a single slide revision — there's no graceful middle ground where it's just a little harder to read. You'll know it's broken because you'll catch yourself explaining the chart out loud instead of letting it explain itself, which is usually the tell that it should've been a table all along.

A hypothetical worth sitting with

Say a team is comparing three vendor proposals — call them Vendor A, B, and C, purely illustrative — across six weighted criteria: cost, support responsiveness, integration effort, security posture, scalability, and contract flexibility. As a table, that's eighteen cells, and the reader has to hold six numbers per vendor in their head to notice that Vendor B is strong everywhere except integration effort, where it's badly behind.

As a radar chart with three overlaid polygons, that gap is visible on first glance — Vendor B's shape has a dent exactly where the others don't. That's the use case in miniature: not "radar charts look better," but "the reader's actual question was about shape, and the table was hiding the answer inside arithmetic they hadn't done yet."

Flip the criteria to something like monthly invoice totals across twelve months, and the same three-entity comparison should go straight back to a table or a line chart — there's no shape to find in numbers whose order matters more than their silhouette.

Building one without it turning against you

A few things I've learned mostly by getting them wrong first, in chart templates and elsewhere:

  • Normalize every axis to the same scale before plotting — a radar chart mixing percentages with raw counts will produce a shape that's technically accurate and practically meaningless.
  • Cap overlapping entities at two or three. Past that, switch to small multiples — one radar per entity, side by side — rather than stacking more shapes into one chart, which is the fix most articles bury in a footnote instead of stating as the default.
  • If more than one axis in the set needs an exact number quoted back later, that's a sign the underlying data wants a table, and the radar chart should be a companion visual rather than the primary one.

For anything with more axes or entities than a radar chart can hold, a comparison table still does the job — and for structural or process comparisons rather than scored ones, it's worth checking whether a different diagram format fits better than either. When the radar chart is the right call but building each polygon from scratch is eating the afternoon, starting from an existing chart template tends to save more time than it costs in customization.

The next time someone reaches for a radar chart out of habit, the useful question isn't whether it looks more sophisticated than a table. It's whether the thing you're actually asking the reader to notice is a number or a shape — because that answer, more than any design rule, decides which one was right.