Choose the right chart by naming the question first: comparing values between groups calls for a bar chart, following a measure over time calls for a line chart, showing a distribution calls for a histogram or box-style summary, showing a relationship between two measures calls for a scatter plot, and splitting a whole into parts calls for a bar chart again in most real cases — a pie chart only when there are very few parts, the parts genuinely exhaust a whole, and the differences between them are large. The worked case in this article uses one small dataset three ways to make that concrete: order totals by city — Madrid 75.00, Berlin 70.50, Paris 64.50, London 57.00, and one city-less order of 30.00, totalling 297.00. As a sorted bar chart the ranking is instantly readable. As a pie, the three middle slices claim 25.25%, 23.74% and 21.72% of the whole — angles so close that the chart's own geometry cannot rank the cities it exists to compare. Our Chart Builder offers the common chart types — bar, line, pie, doughnut, scatter and histogram — so you can make exactly this comparison before committing.

The dataset, and exactly where its numbers came from

Every figure in this article comes from one table: the 10-row cleaned orders file built up across this project's data guides. Method, stated once and applying to all three presentations: the cleaning pipeline in the CSV Cleaning Studio code (applyOperations in csv-studio.js) transformed the original messy 12-row fixture — trim, title case, ISO dates, two empty Amount cells filled with the column median 28.5, deduplication on Order ID keeping first occurrences — leaving 10 rows; a small purpose-built Node aggregation script then grouped those rows by City and summed Amount. (No chart below was rendered by the Chart Builder for this article; the argument is about the resulting tables, which any charting tool would render.) The aggregation's output:

City Orders Total amount Share of 297.00
Madrid 2 75.00 25.25%
Berlin 2 70.50 23.74%
Paris 2 64.50 21.72%
London 3 57.00 19.19%
(blank city) 1 30.00 10.10%

The shares are each city's total divided by 297.00, multiplied by 100 — 75.00 ÷ 297.00 = 25.25%, and so on — and they sum to 100.00%. Two structural features of this table drive everything that follows: four of the five values sit within a narrow band (57.00 to 75.00), and one category, the blank city, is not a place at all but a gap in the data wearing a category's clothes.

Presentation 1: a sorted bar chart — the question answered directly

Read the table above as a bar chart, longest bar first: Madrid, Berlin, Paris, London, blank. Four properties do the work. Every bar starts at the same zero, so lengths are honest ratios — Madrid's bar really is about 1.3 times London's, matching 75.00 against 57.00. The sort order puts the ranking in the picture: first is first, no legend lookup, no angle estimates. Each bar can carry its exact value as a label without clutter, because there are only five. And the blank-city bar can sit at the end, visually demoted by its label (blank city), still present so the bars reconcile to the file's total, not pretending to be a fifth destination. For the question "how do order totals compare by city?", this is the whole answer. The Government Analysis Function's chart guidance maps this relationship — ranking and magnitude — to bar charts for the same reason: position and length along a common scale are the visual channels readers judge most accurately.

Presentation 2: a line chart — a shape the data does not have

Now connect the same five values with a line, in any order. A line asserts two things: that the horizontal axis is continuous, so halfway between two plotted points means something, and that the movement between points is the story. Neither holds here. There is no position "between Paris and London"; cities are names, not a scale, and reordering the (alphabetical? by-total?) axis redraws the "trend" into a different shape with the same data — a chart whose message changes when you shuffle its labels is not showing a pattern, it is manufacturing one. Lines belong to the month table from How to Turn CSV Data Into Useful Charts — January 136.50, March 76.50, April 84.00 — where the axis is time, the order is given by the world, and even there the missing February must be handled openly rather than bridged. Rule of thumb: if you cannot state what the midpoint between two neighbouring points would mean, a line is the wrong chart.

Presentation 3: a pie chart — where it concretely misleads

A pie of the city table makes three distinct errors, each visible in the numbers.

Near-equal slices cannot be ranked by eye. Madrid's slice is a 25.25% wedge (about 90.9°), Berlin's is 23.74% (about 85.5°) and Paris's is 21.72% (about 78.2°). The difference between first and third place is roughly 12.7 degrees of arc, with no common baseline and the slices starting at whatever angle the renderer chose. Readers are poor at comparing angles — that is a known weakness the official guidance cited below designs around — so the pie's central message becomes "these cities are all about a quarter," erasing the ranking the data contains and that the bar chart shows for free.

Too many categories fragment the whole. Five slices is already past the comfortable limit for this chart type, and one of them is the 10.10% blank-city slice. In a pie there is no honest place to put it: include it and a tenth of your chart is a non-city drawn with the same visual weight as Madrid; exclude it and the remaining shares must be recomputed over 267.00 to close the circle, silently promoting every city (Madrid becomes 28.09% of the drawn whole) — numbers nobody computed from the file.

A pie invites a part-to-whole reading the data may not support. Slices sum to 100%, which asserts "this is all of something." Our five groups do exhaust the file's 297.00 — but only because the blank row was kept. The moment a dataset is a top-five list, a sample, or a set of overlapping categories (a customer who bought both Books and Games), the pie's closed circle is a false claim, not a style choice.

None of this bans pies. With two or three parts, differences that are large (a 70/30 split), and a whole that is real, a pie is compact and familiar. This dataset fails all three conditions at once — five parts, near-equal leaders, and a remainder category — which is why it is such a useful test: if your proposed chart is a pie, run these three checks before you draw it.

A short decision procedure

  1. Comparison or ranking between groups → bar chart, sorted descending unless the groups have a natural order. (City totals: bars.)
  2. Change over time → line chart if periods are many and roughly even, column chart if few; account for missing periods explicitly. (Month totals: columns with February shown at zero, or a line with the gap unbridged.)
  3. Parts of a genuine whole → bar chart by default; pie only if there are at most about four parts, the parts exhaust the whole, and no two shares you care about distinguishing are close.
  4. Distribution of one measure → histogram: bin the values and count per bin. Neither bars-per-group nor a pie shows a shape of spread.
  5. Relationship between two measures → scatter plot, one point per row, because the claim is about co-movement, which no aggregation into groups can show.

Underpinning all five: never encode a value by colour alone (the W3C accessibility guidance on use of colour makes the same demand of web content generally), label values directly where the chart stays readable, and publish the table behind the chart — every presentation in this article was argued from its table, and a reader with the table can check any of them. If your data is not yet clean enough to produce a table you would publish, that is the actual problem to fix first; How to Remove Duplicates and Handle Missing Data covers the two faults that most often corrupt one.

Frequently asked questions

When is a pie chart actually the right choice?

When all of these hold: the parts are few (two to four), they genuinely sum to a meaningful whole, the differences between the parts you are highlighting are large, and no category is a remainder or "other" of any size. A 70/30 split of a complete total qualifies. Our city table — five parts, leaders at 25.25%, 23.74% and 21.72%, plus a 10.10% blank — fails on every count.

Why do readers find pie slices hard to compare?

Because the judgment is angle-and-area against no common baseline, starting from an arbitrary rotation. The bar chart replaces it with length along a shared zero baseline, the most accurate elementary judgment readers make. The measured consequence in our dataset: first-to-third place is a 12.7° difference in the pie, and an unmissable length difference in the bars.

My categories have a natural order — should I still sort a bar chart by value?

No. Sorting is for rankings. If the categories are ordered by the world — months, age bands, sizes — keep that order and let the bar heights carry the comparison. Sorting January, March, April by total would destroy the time reading that is the chart's reason to exist.

Can I just show both a pie and a bar chart and let readers choose?

You can, but it doubles the surface for inconsistency — one chart will quietly omit the blank category or the missing month — and it usually means the question was never decided. Pick the chart that answers the stated question, publish the table with it, and readers who want the other view have everything they need.

What do I do with an "Other" or blank category?

Keep it visible and labelled as what it is, as our bar presentation keeps (blank city) at 30.00, or exclude it only with an explicit note and totals that still reconcile. Folding it silently into a neighbour, or letting a pie absorb it, changes every share in the chart without telling anyone.

References