21 CSS Pricing Tables

A pricing section is the whole marketing surface — usually a full-width slab with an H2 headline, a billing toggle, three plan cards, and a footer CTA ("Not sure? Talk to sales"). It occupies its own scroll region on a marketing page and its job is to hand the visitor a decision ("pick a plan"). Our sibling css-pricing-sections collection covers 15 patterns for that surface. A pricing table is the more granular UI primitive — either the 3-card comparison grid inside the section, OR a wide feature-comparison table that sits BELOW the section for visitors who want to compare features across all plans before deciding. It's a smaller unit; a real SaaS page (Vercel, Linear, Stripe, Notion, Framer) ships BOTH — the pricing section at the top for the quick decision, the comparison table below for the deep dive. This collection covers the pricing-table surface: the plan cards, the interactive toggles/sliders/tabs that drive them, the ribbons and badges that guide attention, the comparison matrix rows, the accordion mobile fallback. Copy them alongside the pricing section from the sibling collection, or drop a single card into any layout. All 21 designs are scoped under .prc-NN so they never collide with your existing styles.

The canonical recipe is a hidden radio group (<input type='radio' name='billing' id='monthly' checked> + <input type='radio' name='billing' id='yearly'>) that drives price display via the sibling combinator or, cleaner in modern browsers, :has(). Two <span> elements per card hold the monthly and annual prices — CSS shows one and hides the other based on which radio is checked: .prc-01:has(#yearly:checked) .price-monthly { display:none } .prc-01:has(#yearly:checked) .price-yearly { display:block }. A sliding pill indicator inside the toggle rides transform:translateX(100%) on the checked state. Demo #01 in this collection ships the full recipe — real radio inputs so keyboard users get arrow-key navigation and screen-reader announcement for free, aria-live='polite' on the price so the value change is announced when it swaps. The whole switch is ~40 lines of scoped CSS and zero JavaScript. If your billing is more complex (annual saves 17%, quarterly saves 8%, per-seat pricing), the same pattern extends to 3+ radios — the CSS scales linearly. Vercel, Linear, Stripe, Notion, and Framer all ship this exact pattern on their marketing pricing pages.

The honest answer depends on what you're comparing. Use real <table> markup when you have 15+ features to compare across 3-5 plans — anything long enough that a visitor needs to scan down a column or across a row. Screen readers announce row/column headers correctly (add scope='col' to the plan headers and scope='row' to each feature name), keyboard users navigate cell by cell with arrow keys when the table is focused, and CSS position:sticky on the <thead> pins the plan headers while scrolling the feature rows — no JavaScript needed. Demo #03 (Expandable Feature Comparison Rows) uses this pattern. Use CSS Grid when you're showing 3-6 plan cards side by side with a handful of key bullets each — a card grid, not a comparison matrix. Grid gives you more layout flexibility (visual popouts, ribbon overlays, hover effects) and mobile-first responsive behavior is cleaner. Demos #04, #05, #06, #08, #09, #10, #15, #16, #17, #18 ship this pattern. Never use CSS Grid for a 20-row feature comparison — you lose the automatic table semantics that assistive tech relies on, and mobile users can't scan the data as a table. And never use a <table> for the 3-card marketing grid — it forces the layout into a rigid 3-column shape that breaks on mobile without JS gymnastics.

Demo #06 (Most Popular Border-Beam Glow) shows the modern recipe: use @property to declare a typed custom property for the gradient angle (@property --angle { syntax:'<angle>'; initial-value:0deg; inherits:false }), then animate that property with a conic-gradient border via border-image or a mask+background technique. Because the property is typed as <angle>, browsers can interpolate it on the compositor thread — the border rotation runs on GPU, not on the main thread. That means zero INP impact, zero CLS (the border stays exactly the same size while it rotates), and no scroll listener or requestAnimationFrame loop. Older browsers that don't support @property fall back to a static gradient border via @supports gating — visually degraded but still readable. Do NOT animate the border with a <canvas> element (each frame is a paint), don't use a JavaScript loop that mutates style.background (main-thread work), and don't stack a full-size ::before pseudo-element with filter:blur() for the glow — the filter forces the entire card into a compositor layer which can cost 4-8MB of GPU memory on mobile. The @property + conic-gradient version costs ~200KB GPU memory.

Every demo works in evergreen Chromium, Safari 15.4+, and Firefox 121+. The two features with narrower support are gated with @supports so older browsers get a graceful fallback: (1) :has() — Chrome/Edge/Opera 105+, Safari 15.4+, Firefox 121+ (December 2023). Demos that use :has() for state-machine logic (billing toggle, dark-mode switch, tab crossfade) fall back to ~ sibling combinators or checkbox-hack patterns where possible. (2) @property for typed custom properties — Chrome/Edge 85+, Safari 16.4+, Firefox 128+ (July 2024). Demos that use it for animated gradients (Most Popular border-beam, gradient border draw-in) fall back to a static gradient. Every backdrop-filter declaration ships with the -webkit-backdrop-filter prefix for Safari. Container queries (Demo #20's mobile accordion) work in Chrome 105+, Safari 16.0+, Firefox 110+. If your target audience still includes IE11 or pre-2023 mobile Safari, the fallback story is the demo without the interactive garnish — the plan cards still render, the prices still display, only the delighter (glow, morph, crossfade) is missing. That's the correct progressive-enhancement contract for a marketing surface where conversion depends on the plan info being visible, not on the animation.

Every modern tier-1 SaaS pricing page follows the same three-surface pattern, and this collection ships every piece: (1) Above the fold — the pricing section: full-width slab with H2 headline, monthly/annual toggle (Demo #01), 3-4 plan cards (Demos #04-#10). One card is visually elevated with a 'Most Popular' badge (Demo #06 border glow, Demo #07 floating badge, Demo #17 corner ribbon). Each card ends with a primary CTA (Demo #08 morphing arrow). (2) Middle of the page — interactive calculators: usage-based tiers get a volume slider (Demo #11 — Twilio SMS, SendGrid emails, Cloudflare Workers, OpenAI API tokens), bundle pricing gets a checkbox matrix (Demo #14 — Notion + Slack + Linear bundles), enterprise multi-product suites get tabbed panels (Demo #12 — Google Workspace, Microsoft 365, Adobe Creative Cloud). (3) Below the fold — the comparison matrix: expandable feature rows (Demo #03) let users compare every feature across every plan without leaving the page. Mobile stacks the whole grid into an accordion (Demo #20). The conversion lift from shipping ALL THREE surfaces vs just the pricing section is real: Stripe's own case study data shows the comparison matrix increases conversion for Enterprise-tier plans by 30-40% because the extra feature detail closes the technical-buyer objection. B2B SaaS pricing pages typically run $15-25 CPM in tier-1 markets — one of the highest-value advertising surfaces on the web.

Usage-based billing (fintech's fastest-growing pricing model — 45% of SaaS pricing pages will include it by 2027 per OpenView benchmarks) needs an interactive calculator that shows the total price responding to the user's usage inputs. Demo #11 (Interactive Volume Slider Pricing) is the canonical pattern: a scoped <input type='range'> drives a CSS custom property (--seats) via a two-line JS oninput handler; that property flows down through the plan card and multiplies the base rate to display the total. The whole calculator is ~30 lines of scoped CSS + 15 lines of vanilla JavaScript, zero framework. Demo #14 (Multi-Product Bundle Checkbox Matrix) extends the pattern to the bundle-pricing surface — check boxes for individual products, checkbox-hack toggles a bundle discount, the total updates via CSS counter() on the checked count plus a small JS adder. Real fintech surfaces (Stripe's own stripe.com/pricing, Paddle's checkout, Chargebee's billing plans, Recurly's usage tiers) all use this exact primitive. High-CPM keywords in this vertical: SaaS billing calculator ($15-25 CPM), Stripe usage-based pricing ($25-45), Cloudflare Workers pricing calculator ($15-25), Twilio SMS pricing calculator ($10-15), OpenAI API pricing calculator ($15-25 — surging as of 2025). Every calculator ships aria-live='polite' on the total so screen readers announce the value change; every range input carries a bound <label>, aria-valuemin, aria-valuemax, and aria-valuenow updated by the JS handler.

Pricing pages are unusually exposed to accessibility and consumer-protection enforcement because they're the point where money is committed. Four hard requirements: (1) WCAG 2.2 tap targets (SC 2.5.5) — every clickable pricing card, plan CTA, billing toggle, and comparison-row expander must be at least 24×24 CSS pixels (2.2 relaxed the earlier 44×44 to 24×24 for pointer devices; keep 44×44 on touch surfaces where the space allows). Every demo in this collection is compliant by default. (2) US California SB-478 (2024) — 'junk fees' law: any mandatory fee (setup fees, per-seat surcharges, mandatory add-ons, activation fees, cancellation fees) MUST be included in the displayed advertised price. You can't show '$29/mo' at the top and reveal '+$5 setup fee, +$3 processing fee, +$2 tax' at checkout. Similar laws are on the books in Colorado (SB23-093), Washington DC, and effective 2026 in Massachusetts. Federal FTC 'Rule on Unfair or Deceptive Fees' (October 2024) codifies this nationally for hotels and event ticketing; SaaS is next. Demo #04 (Adaptive Cards) ships a compliant pattern — the visible price includes all mandatory recurring costs; only truly optional add-ons appear below the line item. (3) EU VAT display (Directive 2011/83/EU Article 6): prices shown to EU consumers must include VAT — you can't show '$29 (excl. VAT)' in the primary display. Your pricing table needs to detect visitor geography (server-side, via IP or a locale cookie) and show VAT-inclusive prices to EU visitors. Adjust the --price-base custom property on the demo cards; the rest of the layout is unchanged. (4) FTC Section 5 — deceptive design: 'dark patterns' that obscure the true cost (misleading toggle defaults, hidden fine print, decoy pricing where the middle plan is visually elevated but functionally worse) invite enforcement. Demo #06's 'Most Popular' glow is legitimate emphasis when the elevated plan is genuinely the best value for the median customer; it becomes a dark pattern when the elevation is manipulating attention toward the highest-margin plan regardless of user value. Ship honest emphasis or ship no emphasis; the middle option is legally the worst.