Wensity

React comparison section components

5 comparison section componentsLive previewFull source in your repo

A comparison section has to put two products on the same rows. These comparison tables print the limits, the prices and the missing marks in one grid, so the visitor is not left rebuilding a spreadsheet.

Browse all comparison blocksRead the docs

Works with

  • React
  • Next.js
  • TypeScript
  • Tailwind CSS

Comparison table blocks you can copy

Each block is one file covering the columns, the feature rows and the responsive rules. Preview it live, then copy the source into your project.

Pricing tables to place after a comparison

Pricing sections from the same library, for the page that has already named the competitor and now has to print the price.

Comparison sliders, metric cards and table components

For comparisons a matrix cannot show: a before and after image slider, a KPI card with a sparkline, and the table and chart primitives for a custom grid.

Comparison table design: your plans, rival products or benchmarks

A comparison table puts products in columns and the things buyers care about in rows, so the differences can be read across a single line. On a landing page it does one of three jobs: comparing your own plans, comparing your product against named rivals, or comparing scores on a benchmark. Each job needs a different table, and mixing two in one grid is the most common way a comparison section fails.

Your own plans call for a pricing comparison table. Comparison Section With Simple Pricing groups the rows under Usage, Essentials and Advanced, puts an annual or monthly switch in the header, and tints each of its three plan columns so the seats read as separate offers. Comparison Section With Compare Plans is the compact version: three plans, prices and buttons in the header, purple type on the featured plan, and checks or crosses on every row.

Rival products call for a product comparison table. Comparison Section With Features Matrix sets three named products as wordmarks across the top, prints a value in every cell, and sets the stronger value in brighter type, with a circular mark where a product lacks the row. Comparison Section With Leader Graph makes the same argument as a bar chart, with four logos under the plot and a blue gradient bar on the leader, which suits a single headline number rather than a list of limits.

Scores call for a benchmark table. Comparison Section With Benchmark Matrix frames four models in a square box, runs a blue column for the featured model from header to last row, and fills every winning cell in blue, including wins outside that column. A reasoning row can stack two captions in one cell, so a with tools score and a without tools score sit together.

A few comparison table design rules hold across all five. Use hairlines rather than thick borders, so the table reads as a document rather than a dashboard widget. Let the winning value read first through weight or colour, not through an extra badge. Write row labels in the words a buyer would use on a call. Prefer a value to a checkmark wherever a limit exists, because twenty users says more than a tick.

Keep it to three or four columns. A features matrix tops out at three products and a benchmark matrix at four models. Past that the table turns into a spreadsheet, the eye loses the row, and the visitor stops comparing. On a phone the matrix keeps its columns and scrolls sideways so the row labels stay readable.

Naming a competitor raises the bar on accuracy. Every value in a rival's column has to be true today and checkable from their public pages, because the first person to verify it may be their sales team. Plan prices, wordmarks, model names and eval figures in these blocks are samples. Replace them with numbers you can stand behind, and hide a row rather than printing Custom in a cell you cannot fill.

Place the comparison after the product has proved itself, under a feature section or a short pricing band, and follow it with a decision rather than another grid. One matrix is already an argument. The next section should be pricing, a FAQ or the checkout.

Frequently asked questions

It is a grid that lists products or plans as columns and features, limits or scores as rows, so a visitor can compare options line by line. On SaaS sites it is most often used to compare pricing plans, to compare a product against named competitors, or to show benchmark results.

Run the Wensity CLI with the block slug, for example npx wensity@latest add comparison-section-with-features-matrix --type block. The CLI writes the component into your codebase and pulls in the packages it needs. You can also open any comparison section on this page and copy the source from the Code tab. There is no provider to wire up.

Use Comparison Section With Simple Pricing or Comparison Section With Compare Plans when the columns are your own plans. Use Comparison Section With Features Matrix when named products need to share the same rows, and Comparison Section With Leader Graph when one number makes the case. Use Comparison Section With Benchmark Matrix for model or performance scores.

Three or four. The features matrix tops out at three products and the benchmark matrix at four models, because the cells are scores rather than sentences. Five columns of values turn into a spreadsheet. If you need a vendor catalogue, a comparison section is the wrong tool.

Yes. The matrix keeps its columns and scrolls horizontally on a phone so the feature names stay readable rather than being squeezed. Test the longest row label at a 360 pixel width before you ship.

After the product has proved itself, usually under a feature section or a short pricing band. It should not be the first screen. By the time someone is reading limits they have already decided the category is in the set. One matrix, then a FAQ or checkout.

Where to go next