Typography Systems for Commerce (Readability = Revenue)

A good ecommerce typography system is not a font pairing you picked because it looked nice in a mockup. It is a small, deliberate type scale (five to seven sizes, not fifteen), a body font set no smaller than 16px with generous line-height, and consistent contrast and spacing rules that make prices, variant options, and calls-to-action scannable in under a second. Get those fundamentals right and you remove a whole category of friction that quietly taxes conversion on every single page view.

Typography is the part of ecommerce design that gets the least glamorous attention and does the most measurable work. Nobody screenshots your line-height for a portfolio, but every shopper reads your price, your shipping note, and your size chart before they buy anything. If that reading experience is even slightly effortful — text too small, too tight, too low-contrast, too inconsistent from page to page — you are adding friction at the exact moment a shopper is deciding whether to trust you with their money. This guide covers how to build a typography system for a commerce site properly: the scale, the pairing logic, the accessibility floor, responsive behavior, and the commerce-specific edge cases (prices, badges, option pickers, dense PDPs) that generic type advice usually skips.

Why Typography Is a Revenue Lever, Not a Style Choice

Every ecommerce page is fundamentally a reading task disguised as a shopping experience. Shoppers scan product titles, compare prices, parse variant options, and read trust copy (return policy, shipping estimate, stock status) before they commit to a purchase. Each of those is a small comprehension task, and typography is the interface for all of them. When type is legible, well-contrasted, and consistently sized, comprehension is nearly free — the shopper's attention goes to the decision, not the decoding. When type is cramped, low-contrast, or inconsistently scaled across templates, the shopper spends attention on parsing the page instead of evaluating the product, and some percentage of them will simply leave rather than push through the friction.

This matters more on commerce sites than on almost any other type of site because commerce pages are unusually text-dense in ways that are easy to overlook. A single product detail page might contain a title, a price (sometimes two, with a strikethrough), a rating count, a short description, three to six variant option groups, a size guide link, a shipping estimate, an accordion of policy details, and related-product cards — each with their own title and price. That is a lot of distinct pieces of information competing for the same visual field, and a typography system is the tool that keeps them legible and hierarchically clear rather than turning into visual noise.

Step 1: Build a Small, Deliberate Type Scale

Start with a scale of five to seven sizes, not an open-ended set of ad hoc font sizes sprinkled across components. A workable commerce scale looks something like: a small/caption size (12–13px) for metadata like SKU numbers or badges, a body size (16px) for descriptions and policy copy, a slightly larger UI size (18px) for things like option labels, a subhead size (20–24px) for section headings and product titles on cards, an H2-equivalent (28–32px) for section headings on category and content pages, and a hero/H1 size (36–48px) for landing pages and the top of long-form content. Using a modular ratio (1.2 to 1.333 works well for commerce, where you want density more than dramatic contrast) keeps the sizes feeling related rather than arbitrary.

The discipline that matters more than the exact numbers is refusing to add a new size for every new component. When a designer hands over a mockup with a "product title" at 22px and a near-identical "collection title" at 23px, that is not intentional hierarchy — it is scale drift, and it accumulates into a system where nothing lines up and every new page feels like it needs its own custom sizing decision. Map every text element in your component library to one of your scale steps before you ship it, and treat a request for an off-scale size as a signal to either reuse an existing step or deliberately extend the scale, not a one-off exception.

Step 2: Choose (or Pair) Fonts for Reading, Not for Vibes

Font choice on a commerce site should be evaluated primarily on reading performance, and only secondarily on brand personality. A typeface with low x-height, tight default letter-spacing, or ambiguous character shapes (a lowercase "l" that looks like a capital "I", a "0" indistinguishable from an "O") will slow every shopper down slightly, and that cost compounds across every price and every option label on the site. Before committing to a display or brand font, test it specifically at your body-copy size, not just at the large hero size it looked good at in a type specimen.

A safe, well-tested pairing structure for commerce is one font for display/headings (which can have more personality — tighter tracking, more character) and one highly legible, slightly more neutral font for body copy, UI labels, and prices. Prices in particular benefit from a font with well-designed tabular figures (numerals of equal width), so a column of prices in a comparison table or cart summary lines up cleanly instead of jittering left and right as digit widths vary. If you are using a variable font, this is also where you can lean on a single font family with multiple weights instead of two separate typefaces — fewer font files to load, and less risk of two fonts clashing stylistically.

System fonts are a legitimate, fast choice

Don't dismiss the system font stack (San Francisco on Apple platforms, Segoe UI on Windows, Roboto on Android) as a compromise. System fonts load instantly because they are already on the device, they render with excellent hinting on every screen they are designed for, and modern versions are genuinely well-designed for UI-dense reading. For a store optimizing hard for performance and reading clarity over brand distinctiveness, a system font stack for body copy paired with one custom display font for headings is a defensible, fast-loading system — not a downgrade.

Step 3: Set a Body Size and Line-Height Floor

Sixteen pixels is the practical floor for body text on a commerce site, and there is little reason to go smaller anywhere shoppers are expected to read rather than skim. Product descriptions, policy text, checkout copy, and form labels should all sit at 16px or above. Anything smaller shifts from "reading" to "deciphering" for a meaningful share of your traffic — older shoppers, anyone on a lower-quality screen, anyone in bright sunlight looking at their phone. The instinct to shrink text to fit more onto a screen almost always trades a small layout win for a real comprehension cost.

Line-height (leading) deserves as much attention as font size and gets far less. For body copy, a line-height between 1.4 and 1.6 times the font size keeps paragraphs comfortable to scan without the lines feeling disconnected from each other. Headings can run tighter — 1.1 to 1.3 — since they are short and don't need the same breathing room. Line length matters too: body paragraphs read best around 50-75 characters per line, which on a commerce site usually means constraining description and policy text to a column width rather than letting it stretch full-bleed across a wide desktop viewport.

Step 4: Contrast and Color Are Part of Typography

A typeface choice does not matter if the text is rendered in a color that barely clears the background. WCAG's contrast guidance is a genuinely useful floor here, not just a compliance checkbox: 4.5:1 contrast ratio for normal body text, 3:1 for large text (roughly 18px bold or 24px regular and up). Many commerce sites quietly fail this on secondary text — the light-gray "in stock" note, the muted shipping estimate, the low-opacity disclaimer under a price — because designers reach for a lighter gray to signal "less important" without checking whether it is still legible. Deprioritize information with size, weight, and spacing first; only lean on reduced contrast as a last resort, and check the actual ratio when you do.

Color also carries meaning on commerce pages in ways generic type advice doesn't cover: a strikethrough original price, a sale price in an accent color, a stock warning in a cautionary tone, a shipping-eligible checkmark in a confirming tone. Keep this vocabulary small and consistent — one color for "urgency/scarcity," one for "success/confirmation," one for "sale/discount" — and apply it identically across every template. A shopper who has learned that orange text means "low stock" on the PDP should see the same convention on the cart page and the collection grid, not a different ad hoc color each time.

Step 5: Handle Commerce-Specific Typography Problems

Prices need their own rules

A price is the single most consequential string of text on a commerce site, and it deserves deliberate typographic treatment rather than falling out of a generic type scale by accident. Use tabular (fixed-width) figures wherever prices appear in a list or comparison so digits align vertically. Give the current price clearly more visual weight than a struck-through original price — a heavier weight and a size step up is usually enough; don't rely on the strikethrough alone to establish hierarchy, since screen readers and quick visual scans can both miss it. Decide once, system-wide, whether currency symbols and decimal cents run smaller and superscript-style (as in $19 with a small raised 99) or full-size, and apply that decision everywhere — mixing the two conventions across a cart, a PDP, and an order summary reads as sloppy even when shoppers can't articulate why.

Variant option pickers are a legibility trap

The moment a product has more than two option groups — color, size, material, a add-on — option labels become one of the densest reading tasks on the page, and it's exactly where a lot of themes let font size creep down to fit more options into a row. Resist that. Keep option labels at or near body size, use weight and spacing (not size reduction) to distinguish selected from unselected states, and make sure disabled/out-of-stock options are visually distinct through more than color alone (a strikethrough or reduced opacity plus a label change, not just a grayed-out swatch that colorblind shoppers may not register as different).

Badges, labels, and metadata shouldn't undercut the floor

Small all-caps badges ("NEW," "BESTSELLER," "LOW STOCK") are a legitimate typographic tool, but they tend to be the place where teams push font size well under 12px because the badge is small and decorative-feeling. Below roughly 11-12px, letter tracking needs to open up noticeably or the badge becomes illegible at normal viewing distance, especially in all-caps where there is no ascender/descender variation to help the eye. If a badge needs to communicate real information (stock level, a return deadline), it needs the same legibility floor as any other functional text, just packaged smaller.

Step 6: Make the System Responsive Without Making It Inconsistent

Type scales need to adapt across breakpoints, but the adaptation should feel like the same system compressing, not a different system on mobile. A common, effective approach is fluid typography — sizing headings with a CSS clamp() function so they scale smoothly between a minimum and maximum size across viewport widths, rather than jumping abruptly at specific breakpoints. Body text is usually safest kept static at 16px across breakpoints rather than fluid, since shrinking body copy on mobile is exactly backward — mobile is where legibility pressure (smaller screens, more glare, more one-handed scrolling) is highest, not lowest.

Pay particular attention to how your scale behaves on dense mobile PDPs, where a title, price, rating, and option pickers are all stacked in a short vertical space above the fold. It's tempting to shrink everything uniformly to fit more above the fold, but that erodes the hierarchy that makes the page scannable in the first place. Better to trim padding and non-essential elements (move a lengthy description below the fold, collapse policy details into an accordion) than to compress every text size until nothing stands out from anything else.

Step 7: Typography in Design Tokens, Not Hardcoded Values

However you build the storefront — a Shopify Liquid theme, a headless Next.js frontend, a Webflow site — the type scale should live as a small set of named tokens (font-size-body, font-size-heading-2, line-height-body, and so on) rather than as font-size values typed directly into dozens of components. This is the same discipline that applies to color and spacing tokens, and it pays off identically: change the body size once at the token level and every template that consumes it updates together, instead of hunting through templates for every place 16px was typed by hand. It also makes a rebrand or a font swap tractable instead of terrifying, since the token names stay stable even when the values behind them change.

This token-first discipline is one of the reasons a well-built Figma UI kit is worth starting from rather than a blank canvas — a properly structured kit encodes the type scale, spacing scale, and color tokens as reusable styles from the first frame, so the handoff to code is a direct token-to-token mapping instead of a designer eyeballing sizes off a mockup. It's a detail we build deliberately into our own Figma UI kits, because a typography system that isn't structured at the design-file level tends to drift the moment more than one person touches it.

Step 8: Test Reading Comprehension, Not Just Visual Polish

Most typography QA stops at "does this look good in the mockup," which misses the actual failure modes that hurt conversion. Test your live pages, not your design file: zoom a product page to 200% and confirm text reflows instead of clipping or overlapping. View pricing tables and comparison grids on an actual mid-range Android phone in direct sunlight, where marginal contrast failures become obvious. Run key templates through an automated accessibility checker for contrast violations, and don't treat "it technically passes WCAG AA" as the finish line — passing the floor and being genuinely comfortable to read at length are different bars, and commerce copy (long descriptions, detailed policies, size guides) benefits from clearing the higher one.

It's also worth periodically auditing your live templates against your own type scale to catch drift — a new promotional banner shipped by a marketing team, a third-party app's injected widget, a checkout page a different vendor controls. These are the places off-scale font sizes and low-contrast text creep back in even on a well-designed core theme, and they're invisible unless someone deliberately checks.

Where This Is Heading: AI Design-to-Code and Typography Discipline

As more commerce storefronts get built with AI-assisted, design-to-code workflows — a Figma file feeding a code-generation tool, or an agent building out a component library from a design system spec — the discipline of a small, tokenized type scale becomes more valuable, not less. A model translating a design into code will faithfully reproduce whatever sizing decisions exist in the source file: a clean scale of six sizes maps to a clean set of components, while a file full of one-off 22px and 23px headings gets reproduced just as faithfully, baking the drift permanently into code. Investing in scale discipline at the design-file level pays off doubly once generation tools are part of the pipeline, because it's far easier for a tool (or a person) to consume a small number of well-named, consistently applied tokens than to infer intent from a scattered set of near-duplicate sizes.

Frequently Asked Questions

What is the minimum body font size for an ecommerce site?

Sixteen pixels is a practical floor for any body copy shoppers are meant to read rather than skim — descriptions, policy text, form labels, checkout copy. Going smaller trades a minor layout convenience for a real comprehension cost, particularly on mobile and for older shoppers.

How many font sizes should a commerce type scale have?

Five to seven is a workable range: a caption/metadata size, a body size, a UI/label size, a couple of heading sizes, and a hero size. More than that tends to indicate scale drift rather than genuine design need — audit any size outside the scale before adding it permanently.

Should I use one font or two on a commerce site?

Either works. A single, well-designed variable font family across multiple weights is simpler to maintain and loads fewer files. A two-font pairing (a more characterful display font for headings, a highly legible neutral font for body and prices) can add brand personality, as long as both fonts are tested for actual legibility at your body-copy size, not just judged at hero size.

Do prices need special typography treatment?

Yes. Use tabular figures so prices align in lists and comparisons, give the current price clearly more weight than a struck-through original price, and pick one consistent convention for how currency symbols and cents are sized across the entire site rather than varying it template by template.

Where should the type scale live in the codebase?

As design tokens (named values like font-size-body or line-height-heading) consumed by components, not as font-size values hardcoded per component. This holds whether you're working in a Shopify theme, a headless Next.js storefront, or any other stack, and it's what makes a rebrand, a font swap, or an AI-assisted design-to-code handoff tractable instead of a manual hunt-and-replace exercise.