Install Figma Charts — it’s free to try → See the pie chart gallery →
The pie chart is the most criticised chart in data visualisation, and most of the criticism is correct. It is also, in a narrow set of circumstances, exactly the right thing to draw — and knowing where that boundary sits is more useful than joining either camp.
The short version: a pie encodes share as angle, and people read angle badly. Give someone two slices at 23% and 27% and they cannot reliably say which is bigger. Give them two bars and they can. So the question is never “is a pie chart bad?” — it is “does this particular chart need the precision I am giving up, and does it need the one thing a pie provides that a bar chart does not?”
Everything below happens inside Figma Charts, a Figma plugin. It runs the real JavaScript charting libraries — Google Charts, Highcharts, D3-based Nivo, ApexCharts and Apache ECharts — inside the plugin window, so what lands on your canvas is the library’s own rendering.
Install Figma Charts from the Figma Community →
Press ⌘/ (Ctrl / on Windows), type Figma Charts, hit Enter, then pick the Pie chip.
A pie chart answers “what is this whole made of?”
The mechanism is a circle divided by angle, where the circle is the total and each wedge is a share of it. That construction has one genuine advantage no bar chart matches: the whole is visible. A pie tells you, without a label, that these parts are all of something and that they sum to 100%. A bar chart of the same numbers shows five bars and says nothing about whether they constitute everything.
That is the trade. You give up accurate comparison between slices, and you get a visual guarantee of completeness. Whenever the completeness is the message — how the budget divides, how traffic splits by source, what proportion of capacity is committed — a pie is doing real work. Whenever the message is which item is biggest, you have traded away the thing you needed.
Use a pie when the parts genuinely sum to a meaningful whole, when there are few enough slices to label directly, and when “roughly a third” is precise enough for the decision the reader is making.
Three cases where it is the wrong chart:
1. The parts do not sum to a whole, or they overlap. This is the error that makes a pie actively false rather than merely imprecise. Survey responses where people could pick several answers do not sum to 100% — drawing them as a pie asserts that they do. Same for overlapping segments, or a “top five” that silently omits a long tail. If your numbers do not add up to the whole, a pie is not a poor choice, it is a wrong one.
2. You need to compare slices that are close in size. Angle judgement is poor enough that similar slices are indistinguishable, and it gets worse when they are not adjacent — comparing a wedge at the top with one at the bottom left means comparing two angles in different orientations, which is harder still. If the reader has to rank the parts, sort them into a bar chart.
3. You are drawing several pies to compare them. Two pies side by side invites the reader to compare wedge to wedge across circles, which is the least accurate comparison in the whole visual vocabulary — and if the totals differ, the same percentage is drawn at the same angle while representing wildly different quantities. Use a stacked bar per group, or small multiples of bars.
The practical ceiling is around five slices. Past that, labels stop fitting, thin wedges become indistinguishable from each other, and the chart turns into a legend with decoration attached. Group the tail into “Other” — and if “Other” ends up the largest wedge, that is a sign the pie was the wrong chart.
A pie takes the name-value shape, which is the simplest in the plugin:
That is it. A pie has no second series; if you have two columns of numbers you have a chart type problem, not a formatting problem — two periods of the same breakdown is a job for a pair of stacked bars, not a pair of pies. Pie charts also accept a linked data source in all five libraries, so they can be fed from a Google Sheet, an API, Airtable or Supabase like any cartesian chart.
Two data cautions specific to pies. First, the library computes the percentages from your raw values — you do not need to convert to percentages yourself, and if you do, make sure they actually total 100 rather than 99.7 after rounding. Second, a value the plugin cannot parse becomes 0, and a zero-value slice is invisible: the category silently disappears from the chart rather than showing as empty. On a pie that is easy to miss, because nothing looks broken.
The Inspector — click an element in the preview to filter the configuration panel to just its options — is particularly handy on pies, where the settings you actually want (label position, slice separation, inner radius) are scattered across the option tree. It works on Highcharts and ApexCharts.
A donut is a pie with the middle removed, and the difference is smaller than the debate about it suggests.
Removing the centre technically weakens the encoding: you are now reading arc length rather than angle from a vertex, which is not obviously better. In practice the difference is negligible at normal sizes, and the hole buys you something genuinely useful — a place to put the total. A donut with the headline number in the middle answers “how much altogether?” and “how does it divide?” in one object, which a pie cannot do without a caption.
Use a donut when you have a total worth stating. Use a pie when you do not, and prefer the slightly stronger encoding. The donut post covers the inner radius, semi-donuts and the KPI-tile case in full.
One thing worth knowing about how the plugin files them: all five libraries can draw a donut, but only ApexCharts gives Donut its own category chip. Highcharts ships donut, 3D donut and semi-circle donut examples inside its Pie category; Google Charts has a donut example there too; ECharts has doughnut and half-donut; Nivo makes one by setting an inner radius on a pie. So if you are hunting for a donut under another library’s tabs, look under Pie rather than concluding it is missing.
The gallery holds 38 pie examples, plus 3 filed under ApexCharts’ separate Donut chip:
A warning about one variant: 3D pies make the encoding worse. Perspective enlarges the slices at the front and compresses those at the back, so two equal shares are drawn at visibly different sizes. It is the one chart decoration that changes the numbers. Avoid it, however good it looks in the gallery.
Label directly, and include the percentage. A legend forces the reader to look back and forth between a colour key and the wedges, which on a pie is worse than on a bar chart because the wedges are radially arranged and hard to scan. Put the category name and its share on or beside each slice, and the legend becomes unnecessary.
Sort by size and start at twelve o’clock. The convention is largest slice first, running clockwise from the top. It is not arbitrary: the top and the clockwise direction are where the eye starts, so the largest share gets the most legible position and every subsequent slice is progressively less important. Break the convention only for a natural order the reader already knows.
Colour is doing real work here, unlike on a bar chart. Every slice is a different category, so different colours are meaningful rather than decorative. That makes a pie one of the few charts where you genuinely need a full categorical palette — which is exactly the kind your design system probably does not have. Your chart, your design system covers building one that actually distinguishes.
Do not explode the slices. Pulling wedges apart removes the shared vertex that made angle readable at all, and the gaps add area that means nothing. If you want to emphasise one slice, colour it and mute the others.
Keep it a circle. An ellipse distorts every angle unevenly — the same share reads differently depending where it sits. If your layout wants a wide box, put the labels beside the pie rather than stretching it.
Angle judgement is genuinely poor, and it is worse than people expect. Readers systematically underestimate large wedges and overestimate small ones. Printing the percentages defuses most of this — and if you find yourself relying on the printed numbers for the chart to work, the honest conclusion is that you have a table wearing a costume.
Rounding can make the parts fail to sum. Three shares of 33.3% display as 33% and total 99%. Readers notice, and it undermines confidence in everything else on the page. Either show a decimal place or note that figures are rounded.
A pie hides magnitude entirely. Two pies with identical proportions look identical whether the totals are 40 and 4,000. If the size of the whole matters — and it usually does — state the total in text, or use a donut with the number in the middle.
“Other” can hide the story. Rolling a long tail into one wedge is good practice for legibility and bad practice when something important is in the tail. Check what is inside “Other” before you ship the chart.
Small slices are unclickable and unreadable. Anything under about 2% is a sliver that cannot carry a label or be distinguished by colour. If those categories matter, they need a different chart.
And the start angle is a rhetorical device. Rotating the pie changes which slice occupies the top-right quadrant — where the eye lands first — without changing a single number. It is the pie equivalent of the truncated axis: entirely legitimate on its face, and easy to use to put your preferred category in the most flattering position. Pick the convention (largest first, from twelve o’clock) and stick to it rather than choosing per chart.
Most of the time the answer to “is this a good pie chart?” is “it should be something else”. The useful part is knowing which something:
The exception that keeps pies in the toolkit: when a stakeholder needs to see at a glance that nothing is missing, the closed circle communicates completeness in a way no bar arrangement does. That is a real communication property, not a concession — just make sure it is the one you need.
Pies depend on colour more than any other common chart, which makes them the worst offender for colour vision deficiency. There is no position or length to fall back on — if two adjacent wedges are indistinguishable, the chart is unreadable, not just harder. Direct labelling fixes this completely, and it is the single most valuable accessibility change you can make to a pie.
Check adjacent slices against each other, not only against the background. Neighbouring wedges share a border, so any two that read as one colour merge into a single apparent slice.
Give it a text equivalent. Copy Data Table in the Export tab produces an HTML table of the categories and values — for a pie this is arguably better than the chart, since it gives exact shares rather than angles to estimate. Copy Alt Text and Set Node Desc handle the summary.
State the total in the text around the chart. Screen-reader users get percentages with no sense of scale otherwise.
From the Export tab, Code writes a component for React, Vue 3, Angular, Svelte or vanilla JavaScript against the same library at the same major version; Config hands over the library’s own options object; Tokens exports colours and type as CSS, SCSS, Tailwind, W3C tokens or JSON.
For pies the config is worth passing over verbatim, because label placement, slice ordering, inner radius and the start angle are all settings a developer would otherwise have to reverse-engineer from a picture. From Figma to code covers all eight formats.
One note if you plan to animate: pie and donut segments cannot morph between states, because their angles have no interpolable correspondence. The plugin recommends Dissolve for them — see the animation post.
They are bad at comparison and good at showing that parts make a whole. Use one when completeness is the message and there are few enough slices to label; use a sorted bar chart when the reader needs to rank the parts or read close values accurately.
About five. Beyond that labels stop fitting and thin wedges become indistinguishable. Group the tail into “Other” — and if “Other” becomes the biggest slice, the pie was the wrong chart.
Donut if you have a total worth putting in the middle; pie if you do not. The encoding difference is negligible at normal sizes, and the hole is genuinely useful space.
Because only ApexCharts gives Donut its own category chip. All five libraries can draw one — Highcharts has donut, 3D donut and semi-circle donut, ECharts has doughnut and half-donut, Google has a donut example, and Nivo makes one with an inner radius — but in the other four they are filed under Pie.
No. Perspective enlarges the front slices and compresses the back ones, so equal shares are drawn at different sizes. It is the one piece of chart decoration that changes what the numbers appear to say.
No — give it raw values and the library computes the shares. If you do supply percentages, check they total 100 after rounding, because three thirds displayed as 33% each visibly fails to add up.
Largest first, clockwise from twelve o’clock, unless the categories have a natural order the reader already knows. Wedges are drawn in data order, so sort the rows in the data table.
Yes — pies take the simple name-value shape and accept a linked source in all five libraries. Watch for unparseable cells, though: they become zero, and a zero-value slice vanishes from the chart entirely rather than showing as empty.
Open a pie, put your real categories in, and count the slices. If there are more than five, the most useful thing this page can do is send you to the bar chart instead — and if there are three or four and they add up to something meaningful, you are looking at one of the few charts a pie does better than anything else.
Install Figma Charts — it’s free to try → Browse all 45 chart types →