shadcn.io is not affiliated with official shadcn/ui
Spec Sheet Columns Pricing Block for Radix UI
Three virtual-server plans laid out like a technical datasheet on the page column: a column per plan with its size, price and call to action, then grouped rows of monospaced specs on shared hairlines, and a plan switch on phones.
Installation
Overview
Present plans like a technical datasheet with this spec sheet pricing section, for React with Radix UI. A left-aligned header carries the headline and one sentence, and a Table spans the page column between its side lines, ruled above and below by Guides with a + mark on each corner. The first row is the plans: each column opens with its name, an outline Best value Badge on the recommended plan, its size in monospace (4 vCPU · 16 GB), its monthly price and a Shine Button call to action; the recommended column is lightly tinted and holds the section's one primary button. Below come grouped rows for compute, storage, network and support, each group opened by a tinted band, with monospaced values and hairlines shared between the columns. Below the md breakpoint a Segment Group picks one plan, and the sheet keeps the spec labels beside that plan's column, in the same ruled rows. Built with Table, Segment Group, Badge, Shine Button, Guides and Lucide icons, with CSS transitions only. Perfect for virtual servers, cloud compute, developer tools and any B2B product whose buyers compare plans on raw specs rather than marketing features.
FAQ
How do I change the plans and the spec rows?
PLANS lists the columns: each plan has an id, a name, a size line, a monthly price, the call to action's cta and href, and popular: true with a badge on the column to tint. SPEC_GROUPS lists the groups, each with a title and its specs; a spec has a label and values, one per plan id. Write a value as it should read ("16 GB", "Hourly × 30"), or null where the plan has none: it shows a dash and reads as "Not included". Add a plan by adding it to PlanId, PLANS and every spec's values; TypeScript flags any row you miss.
How is the datasheet table read by a screen reader?
It is a real table named by the section's heading. Plan names are the column headers and each spec's label is its row's header, so a value is read with both ("Pro, Memory, 16 GB"). Each group is its own table body that starts with a header for the whole group, so moving into the Storage rows announces "Storage". Prices sit in a row headed "Price", and each call to action carries its plan's name ("Deploy server, Pro plan").
What do phones see?
Below md a plan switch (a radio group) appears over the table with the recommended plan selected, and the table shows the spec labels beside that one plan's column: its name, size, price and call to action first, then every group. Nothing scrolls sideways, and switching plan swaps the column in place. Both layouts are rendered from the same data and the one not in use is display: none, so assistive technology meets only one. From md the three columns fit side by side.
How do I link each column to checkout or sales?
Each call to action is a real link to its plan's href: send the plans to your deploy flow with the plan in the URL (/deploy?plan=pro), and point a top plan at your sales form if you sell it by quote.
The link is the a inside ShineButton asChild; put your router's link there if you have one.
How does the datasheet animate in?
The header fades and lifts in, then the table follows 150 milliseconds later. It's all CSS transitions with @starting-style, no JavaScript, and the rows themselves don't animate, since a transform on a table row isn't reliable across browsers. With reduced motion on, everything shows at once.
When should I use a spec sheet instead of feature cards?
Use it when buyers compare numbers: cores, memory, storage, bandwidth, SLAs. Engineers and procurement teams read a datasheet faster than marketing bullets, and monospaced values line up for scanning. For products sold on outcomes rather than specs, plan cards with short feature lists convert better.