Typography. Most of your interface is words.

Warm-up: what do you already see?

Before any theory, test your eye. These three questions are a diagnostic, not a grade. If you get them all right, you already notice type; this guide will give you the vocabulary and the numbers behind that instinct. If you miss them, good: you now know exactly what to watch for as you read.

How to study this guide: read one Part per sitting. Do each chapter’s quiz before you move on, and do at least the exercises marked “on your own product”. Keep your own app open in another window the whole time. Typography is learned with the eyes and hands, so every time you read a rule, look for it in your screen and change one thing.

In software, typography is not decoration on top of the design; for most screens it is the design, so getting type right improves every screen at once.

In 2006 Oliver Reichenstein of Information Architects published an essay called “Web Design is 95% Typography”. His argument was simple: the overwhelming majority of what people consume on the web is written language, so the core skill of a web designer should be shaping written information. Twenty years on, the claim holds for products too. Look at a to-do app, a banking app, a settings screen or a code editor and count the pixels that are text versus everything else. Text is the interface.

This has a practical consequence for you as a solo creator. Type decisions are the highest-leverage design decisions you can make, because they are global. Change the body size, leading and colour once in your CSS or your SwiftUI text styles, and every screen improves. Polish one illustration and one screen improves. If you have limited time (you do), type is where to spend it first.

The crystal goblet

In a 1930 lecture later published as “The Crystal Goblet”, the typographer Beatrice Warde compared good typography to a clear glass: a wine lover wants a goblet that reveals the wine, not an ornate gold cup that hides it. Her point was that type in the service of reading should be invisible. The reader should notice the meaning, not the letters.

That idea is the north star for product typography, with one adjustment. In a product, type has two jobs. In reading mode (an article, a note, a long description) it should disappear. In interface mode (labels, buttons, numbers, headings) it should be instantly scannable, which means it must create clear differences: this is a heading, that is a label, this number matters more than that one. Good product typography is invisible in the first job and quietly structured in the second.

Typography exists to honor content.Robert Bringhurst, The Elements of Typographic Style

What “good” looks like on a screen

Bringhurst wrote for books, Matthew Butterick (Practical Typography) translated much of it for the web, and both agree on the goal: text that respects the reader’s time and attention. On a screen that comes down to five testable qualities, which the rest of this guide unpacks one by one:

1. Comfortable body text. Big enough, with enough line spacing, at a line length the eye can track (Chapter 7).
2. Clear hierarchy with few means. A small set of sizes and weights, each with a job (Chapters 8 and 9).
3. Consistent rhythm. Spacing that follows a system, so related things sit together (Chapter 10).
4. Correct details. Real quotes, proper dashes, aligned figures (Chapters 12 to 14).
5. Robustness. Text that survives long names, large user font sizes, slow networks, Windows rendering and other scripts (Part five).

In the wild

• iA WriterInformation Architects, 2010
  Almost no chrome: the product is a single, carefully set column of text in a custom typeface derived from IBM Plex Mono. Users pay for how the text feels. When type is right, it can be the whole product.
• Things 3Cultured Code, 2017
  Uses Apple’s system font and builds its calm look almost entirely from size, weight, grey values and generous spacing. You don’t need a custom font to look crafted; you need a disciplined system.
• KindleAmazon, 2007 to today
  Amazon commissioned Bookerly (Dalton Maag, 2015) specifically for reading on its screens, and gives readers control of size, margins and line spacing. For a reading product, typography is the core feature, not a skin.

A few measurable parts of a letter (x-height, aperture, contrast, spacing) predict almost everything about how a typeface will behave at screen sizes.

You don’t need to draw type to design with it, but you do need to see it. Spiekermann’s Stop Stealing Sheep & Find Out How Type Works exists because most people look at letters and see only “nice” or “not nice”. Designers see parts. Once you can name the parts, you can predict behaviour: this face will blur at 12px, that one will look huge at 16px, this one will turn grey and weak in dark mode.

Baseline

The invisible line letters sit on. Round letters (o, e) dip slightly below it (overshoot) so they look aligned with flat ones.

x-height

The height of lowercase letters without ascenders, like x, a, e. Because most reading happens in lowercase, x-height determines how big a face looks. Two faces at 16px can differ by 15% or more in apparent size.

Cap height

The height of flat capitals like H. Cap height matters for aligning text to icons and for all-caps labels.

Ascender and descender

The parts of b, d, h, k, l that rise above the x-height, and of g, j, p, q, y that drop below the baseline. Long extenders help word recognition but need more line spacing.

Stem

The main vertical stroke, like the uprights of H or the spine of l. Stem thickness defines weight.

Bowl and counter

The bowl is the curved stroke enclosing a space (in b, d, o, p). The counter is the enclosed or partly enclosed space itself. Small counters fill in with ink, or with blur on low-resolution screens.

Aperture

How open a partly enclosed counter is, in c, e, a, s. Open apertures keep letters distinct at small sizes.

Terminal

The end of a stroke that has no serif, like the top of a or the end of c. It can be ball-shaped, sheared, flat or tapered.

Serif

The small foot or cap at the end of a stroke. Sans serif means without.

Contrast

The difference between thick and thin strokes. High contrast looks elegant in print and large sizes; at small screen sizes the thin strokes can vanish.

Sidebearings and spacing

The built-in space on each side of a glyph. Spacing is as much part of the design as the shapes; loose spacing reads better small, tight spacing looks better large.

Why x-height matters on screens

Screens are lower resolution than print. A 16px letter on a typical display has its x-height drawn with roughly 7 to 9 pixels. Every pixel of x-height you gain makes counters bigger and shapes more distinct. That is why faces designed for screens, such as Verdana and Georgia (Matthew Carter, 1996, made for Microsoft when screens were coarse), have large x-heights and generous spacing. It is also why a classical book face like Garamond looks small and spindly at the same nominal size: its x-height is modest and its strokes are thin.

Why aperture matters

Aperture is the most underrated screen-legibility feature. In a closed-aperture face (Helvetica is the classic example), the ends of c, e, a and s curl back towards each other. That looks tidy and uniform at large sizes. At small sizes, or with blur, motion or low vision, those letters start to look like o. Humanist sans serifs (Frutiger, Source Sans, Fira) keep the apertures open, so each letter stays itself.

Contrast, terminals and other screen risks

High-contrast faces (Didot, Bodoni, Playfair Display) have hairline thin strokes. At 48px on a headline, gorgeous. At 14px on a Windows laptop, the hairlines fall below one pixel and break up. Low-contrast faces with sturdy strokes survive. Similarly, tiny distinctions like the difference between l (lowercase L), I (capital i) and 1 (one) are fine in a novel, where context resolves them, and dangerous in a password, a promo code or a file name. Atkinson Hyperlegible (Braille Institute, 2019) was designed specifically to exaggerate such distinctions for low-vision readers.

In the wild

• Verdana & GeorgiaMatthew Carter for Microsoft, 1996
  Designed for the coarse CRT screens of the 1990s, with large x-heights, wide spacing and shapes that hold up when drawn in few pixels. Screen faces are built around the pixel, not adapted to it.
• RetinaFrere-Jones Type, for The Wall Street Journal
  A face for tiny financial tables, drawn with wide proportions and ink traps so numbers stay distinct at very small sizes. Small text needs a face designed for small text.
• Atkinson HyperlegibleBraille Institute, 2019
  Exaggerated letterform differences (tailed l, slashed zero, distinctive b/d/p/q) for low-vision readers; free to use. Distinctness is a design parameter you can choose.

Typefaces fall into families defined by how their strokes were made; knowing a face’s family tells you its voice, its era and how it behaves on screen before you test it.

Classification is not trivia. Each category comes from a tool and a period: the broad-nib pen of Renaissance scribes, the engraver’s steel, the industrial sign painter, the geometric ideals of the Bauhaus. Those origins left fingerprints in the shapes (where the stress falls, how much contrast there is, how open the letters are), and those fingerprints are exactly what determine screen behaviour. Learn ten categories and you can read a new typeface the way a sommelier reads a label.

The serif families

Old style faces come from the broad-nib pen, which makes thick and thin strokes depending on angle. The thinnest parts of an o sit on a diagonal (the “stress”). Contrast is modest, serifs are bracketed (they curve into the stem), and the whole thing feels warm and literary. They read well in long text, but classic old-style revivals often have small x-heights, so give them more size on screen.

Transitional faces (eighteenth century) straightened the stress towards vertical and sharpened the details. Times New Roman belongs here, and it was drawn for narrow newspaper columns, which is why it is compact.

Didones pushed contrast to the extreme: hairline serifs, vertical stress, ball terminals. Luxurious at magazine-cover sizes; fragile at text sizes on screens.

Slab serifs have thick, rectangular serifs and low contrast. Born for posters, they now include sturdy text faces (Roboto Slab, Zilla Slab) that hold up well on low-quality screens because nothing in them is thin.

The sans serif families

Grotesques were the first commercial sans serifs: slightly irregular, with some stroke contrast. Neo-grotesques (Helvetica, Univers) smoothed them into neutral, uniform shapes with horizontal terminals that curl in, which closes apertures. Humanist sans serifs bring back pen proportions and open apertures (Gill Sans, Frutiger, Myriad, Source Sans), and tend to be the most legible at small sizes. Geometric sans serifs build letters from circles and straight lines (Futura, Avenir, Jost); they are clean and stylish, but their perfectly round o, c, e and single-storey a can blur together in body text.

Most modern UI faces are hybrids. Inter is broadly neo-grotesque but with taller x-height and slightly more open forms tuned for screens. SF Pro sits between neo-grotesque and humanist. Don’t worry about precise labels; use the categories to predict behaviour.

In the wild

• Medium2012 onward
  Long-form posts are set in a serif at a generous size (around 20px) with a sans serif for UI and metadata. Serif for reading, sans for interface is a pattern because it works, not because it is a rule.
• AirbnbCereal, 2018
  A custom geometric-leaning sans gives the brand a friendly, rounded voice across app and marketing. Geometric faces carry brand personality; product teams then tune size and spacing for legibility.
• GitHubSystem fonts, 2017
  Switched its UI to the operating system’s font stack, with a monospace for code and later custom faces (Mona Sans, Hubot Sans) for marketing. Neutral UI, distinctive voice elsewhere.

Reading is a series of quick jumps and short stops; typography helps when it makes each stop easy (legibility) and each jump predictable (readability).

Two words that people use interchangeably mean different things. In Walter Tracy’s classic distinction, legibility is about the typeface: how easily individual characters can be told apart. Readability is about the setting: how comfortably a block of text can be read for a long time, which depends on size, spacing, line length, contrast and layout. A highly legible face can be set unreadably (8px, justified, 140 characters wide), and a modest face set with care can read beautifully.

What the eyes actually do

Your eyes do not glide along a line. They make rapid jumps called saccades and brief stops called fixations. Eye-movement research summarized by Keith Rayner gives typical figures for skilled readers of English: fixations last around a quarter of a second, saccades jump around seven to nine characters, and somewhere around 10–15% of saccades go backwards (regressions) to re-check something. During a fixation you only see detail in a small window, a few letters to the left and more (roughly 14–15 characters) to the right. At the end of each line comes the return sweep, a long jump back to the start of the next line, which is where readers most often lose their place.

The word-shape myth

For decades designers repeated that we read by recognizing the outline of whole words (the “bouma”), and that this is why lowercase reads faster than all caps. In 2004 Kevin Larson of Microsoft’s advanced reading team published a review, The Science of Word Recognition, arguing that the evidence points elsewhere: readers recognize the letters within a word in parallel and use that information to identify the word. All-caps text is slower mostly because we have far less practice reading it, and alternating-case text slows people down because it disrupts letter recognition, not just outline.

Why this matters for you: it means letter distinctness (Chapter 2) is what you are designing for. Don’t justify all-caps paragraphs by saying “outline doesn’t matter”, and don’t justify tiny lowercase by saying “people read shapes anyway”. Make letters clear, words well spaced, and lines easy to track.

Familiarity is a feature

Readers read fastest what they read most. That is a quiet argument for conventional choices: sentence case over all caps, mixed case over small caps for long text, familiar letterforms over quirky ones (a single-storey a or a playful g may charm in a logo and slow down a paragraph). Novelty costs attention. Spend it where you want attention, never in body text.

In the wild

• Microsoft ClearType researchLate 1990s to 2000s
  Microsoft’s reading research group studied how rendering and type affect reading on screens, work connected to ClearType rendering and the ClearType font collection that shipped with Windows Vista (Calibri, Cambria, Consolas and others). Screen reading is a solvable engineering problem, not just taste.
• Apple Books & Kindle2010s–today
  Both let readers choose a font, size and line spacing, accepting that comfort varies by person and eyesight. For long reading, give control; your defaults are a starting point.
• UK GOV.UKGovernment Digital Service
  Uses sentence case almost everywhere, short line lengths and plain sizes, with research behind the style guide. Familiar, unshowy setting serves the widest audience.

Start from the system font and only leave it for a reason you can name; when you do leave it, choose a face built for screens that covers every size, weight, figure style and script you need.

Every font choice is a trade between three things: fit (does it suit your product’s job and voice), function (does it behave at your sizes, with your numbers, in your languages), and cost (licence, file size, loading time, maintenance). Designers new to type over-weight fit. Experienced ones start with function and cost, and let fit choose between the survivors.

Option one: the system font

Each platform ships a superb UI family: SF Pro on Apple platforms (since 2015), Segoe UI on Windows (Segoe UI Variable on Windows 11), Roboto on Android (since 2011, redesigned in 2014). On the web you reach all of them with one CSS stack, and you pay nothing in download size.

font-family: system-ui, -apple-system, "Segoe UI", Roboto,
             "Noto Sans", "Helvetica Neue", Arial, sans-serif;

What you get for free is easy to underestimate. Apple’s SF switches between Text and Display designs (and, in recent versions, uses a variable optical-size axis) and adjusts tracking by size automatically. System fonts support the platform’s Dynamic Type or text scaling. They cover many scripts, they are hinted for each platform’s renderer, and they make your app feel native because they are what everything else on the device uses.

What you give up: distinctiveness (you look like everyone), and cross-platform consistency (your web app will have slightly different widths on Mac, Windows and Android, so layouts must flex). A known wrinkle: on some Windows language settings, system-ui can resolve to a font you didn’t expect, which is one reason some teams list named fonts instead.

Option two: a chosen family

Choose a specific family when you have a reason: long reading where a serif voice matters, a brand that needs a distinctive voice, tabular data that needs particular figure features, or the need for identical metrics across platforms. Then hold the face to a function checklist before you fall for it.

The function checklist

Before committing to any face, check that it has: at least regular, medium or semibold, and bold (four weights is comfortable; a variable font is better); true italics if you set prose; tabular and lining figures (Chapter 13); the punctuation and symbols you use (₹, €, arrows, ×, curly quotes); every script your users write in; good hinting or rendering on Windows if you have Windows users; and a licence that covers how you ship (web, app, ePub, video).

Good free families for screens

In the wild

• Linear2019 onward
  Built its dense, crisp UI on Inter, a free screen family with tall x-height and tabular figures. A free, well-engineered family can carry a premium-feeling product.
• Google Play BooksLiterata, 2015
  Commissioned a reading face from TypeTogether instead of using the UI font for book text. Reading and interface are different jobs and may deserve different faces.
• Things 3, Apple NotesApple platforms
  Both use the system font and system text styles, and both scale with the user’s preferred text size. Native apps gain more from the system face than any custom font could give.

One family is usually enough; when you pair, combine clear contrast in structure with shared proportions, and give each face a distinct job.

Pairing advice is full of folklore (“always pair a serif with a sans”). The underlying logic is simpler. Two faces on one screen should either be clearly the same (one family) or clearly different (contrasting structure). The failure zone is in between: two faces that are almost alike, so the reader senses a difference but can’t tell what it means. That reads as a mistake.

Rules that actually explain pairings

1. Start with one family. A good family with three or four weights and italics gives you more hierarchy than most products need (Chapter 9).
2. If you pair, contrast structure. Serif with sans, or a display face with a text face. Not two neo-grotesques.
3. Share proportions. Faces with similar x-height ratio and width sit comfortably on the same line and in adjacent blocks. Mismatched x-heights make one look shrunken.
4. Share an era or a construction logic when possible. A humanist sans (pen proportions) pairs naturally with an old-style or modern humanist serif. A geometric sans sits well with a didone or a geometric slab.
5. Give each face a job. “Serif for reading, sans for interface” or “display for page titles only”. If you can’t state a face’s job, you don’t need it.
6. Prefer superfamilies. IBM Plex, Source, Noto and Roboto (Roboto, Roboto Slab, Roboto Mono, Roboto Serif) were designed to work together, with matched metrics. The pairing work is already done.

Licensing basics

A font is software, and its licence says where you may use it. You will meet four common situations:

Hosting also matters. Loading fonts from a third-party CDN sends your visitors’ IP addresses to that service; in 2022 a German court found that embedding Google Fonts from Google’s servers without consent violated GDPR. Self-hosting open-licence fonts avoids the issue and is usually faster anyway (Chapter 16).

In the wild

• IBM PlexIBM, 2017
  Sans, Serif, Mono, condensed widths and many scripts in one open superfamily, so products can mix them without pairing problems. Superfamilies remove pairing risk.
• NotionPage styles
  Lets users switch a page between Default (sans), Serif and Mono styles, each a single coherent voice rather than mixed fonts. Offer voices, not font soup.
• The GuardianGuardian Egyptian, 2005
  A single custom family with headline and text cuts in serif and sans styles (Paul Barnes and Christian Schwartz) gives the paper its voice across print and digital. A designed family is the professional answer to pairing.

Body text reads best at 16–20px on screens, with line-height around 1.4–1.6, on lines of 45–75 characters; and the three numbers depend on each other.

These are the three settings that decide whether a paragraph is comfortable. They are not independent. A bigger size needs a longer line in px to keep the same characters per line. A longer line needs more leading so the return sweep (Chapter 4) can find the next line. A face with a tall x-height looks bigger and needs more leading than one with a small x-height. Tune them together.

Size: start at 16, often go higher

Browsers default to 16px, and that is a floor for body text on the web, not a target. Butterick suggests 15–25px for web body text; many reading-focused sites sit at 18–21px. On iOS the default Body text style is 17pt; Android’s Material body sizes are around 14–16sp. People hold phones closer than they sit to laptops, so similar numbers work on both. Text smaller than about 12–13px should be rare and never essential.

Leading: the space between lines

“Leading” comes from the strips of lead typesetters put between lines of metal type. In CSS it is line-height, best written unitless (1.5, not 24px) so it scales with size. For body text, 1.4–1.6 is the usual band; Butterick suggests 120–145% of the point size, and WCAG’s enhanced criterion asks for at least 1.5 within paragraphs. Use the low end for short lines and small x-heights, the high end for long lines and tall x-heights. Headings need less: 1.1–1.25, because large sizes already create space and loose headings fall apart into separate lines.

Measure: characters per line

Bringhurst gives the classic range: 45 to 75 characters per line (counting letters and spaces) for single-column text, with around 66 often cited as ideal. Shorter lines force constant return sweeps and choppy reading; longer lines make the sweep long and error-prone. In CSS set it with max-width in em or ch. Note that ch is the width of the digit zero, which is usually wider than an average letter, so 66ch typically gives somewhat more than 66 real characters. Test with real text, as the lab below does.

Leading relative to measure

The lab’s suggestion follows a simple principle: the longer the line, the more leading it needs. A 40-character mobile column can live at 1.4; a 75-character desktop column wants 1.6 or more. Text with a tall x-height (Inter, Atkinson, Verdana) looks tighter at the same line-height, because the gap between lines (from baseline to the next line’s x-height) is smaller; give it 0.05–0.1 more.

Paragraph spacing or indent, never both

Paragraphs need a signal that a new one has begun. Either add space between them (on screens, typically 0.75–1em, smaller than a full blank line is fine), or indent the first line (1–2em) with no extra space, as books do. Using both double-signals and wastes space. On screens, and especially in UI and documentation, spacing is the norm because text is scanned as much as read. First-line indents suit continuous reading like fiction and long essays.

In the wild

• WikipediaVector 2022 skin
  The 2022 redesign introduced a maximum width for article content after years of full-width text on large monitors. Even the web’s biggest reference work found that limiting line length helps reading.
• Instapaper & Reader modes2008 onward
  Reading modes in Instapaper, Safari Reader and others strip a page and re-set it with a larger size, generous leading and a narrow column. People install products just to fix size, leading and measure.
• iA WriterInformation Architects
  Keeps the writing column at a comfortable measure and scales type with the window, so line length stays reasonable across devices. Line length can be a product feature, not just a style.

Pick five to seven sizes related by a consistent ratio, give each a job, and use nothing else; the relationship between sizes is what makes hierarchy feel intentional.

Look at a product built without a scale and you’ll find 11px, 12px, 13px, 14px, 15px, 16px, 17px, 18px, 20px, 22px, 24px and 28px, each chosen once for one component. The result looks slightly off everywhere, because neighbouring sizes are too close to read as different levels and too far to read as the same. A scale fixes this by making every size a deliberate step.

Modular scales

Bringhurst described the classical scale of sizes used by printers since the sixteenth century, and in 2011 Tim Brown’s article “More Meaningful Typography” (A List Apart) and his modularscale.com tool popularised the idea for the web: start with a base size and multiply by a ratio. With a 16px base and a 1.25 ratio you get 16, 20, 25, 31.25, 39 and so on; dividing gives 12.8 and 10.24 below. The ratios have musical names because they are the same intervals:

/* CSS tokens appear here */

How many sizes you really need

Most products work with five to seven sizes: caption or small, body, a large body or subtitle, two or three heading levels, and possibly one display size for marketing. Material Design 3 defines fifteen named roles (display, headline, title, body and label, each in large, medium and small), and Apple’s iOS text styles define eleven (from Large Title at 34pt down to Caption 2 at 11pt, with Body at 17pt). Notice that Apple’s steps aren’t a strict ratio: they are hand-tuned, with tighter steps in the text range and bigger jumps at the top. That is a good model. Use a ratio to generate candidates, then round and adjust.

Fluid scales

On the web, a heading that is right at 1440px is often too big at 375px. You can use a gentler ratio on small screens and a steeper one on large screens, interpolating with CSS clamp(): for example font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem) for a page title. Keep body text nearly fixed (it should not shrink on phones) and let display sizes flex.

In the wild

• Apple HIG text stylesiOS, iPadOS
  Eleven named styles that scale together with Dynamic Type. Developers pick a role (Headline, Body, Footnote), not a size. Roles survive redesigns and user scaling; raw sizes don’t.
• Material Design 3Google, 2021
  Fifteen roles in five groups, with tokens for size, line-height, weight and tracking per role. A type role is a bundle: size, leading, weight and tracking travel together.
• Tailwind CSSDefault theme
  Ships a fixed set of named sizes (text-xs to text-9xl), each paired with a default line-height. Even utility-first CSS works from a closed scale.

Size is only one of six levers for typographic hierarchy; calm interfaces use weight, colour, case, space and position for most distinctions, and change only one or two levers per level.

Vignelli was famous for working with very few typefaces and a few sizes, and still producing rich, clear hierarchy. The trick is that hierarchy is about difference, and size is the loudest, most space-hungry way to make a difference. In a dense product screen you have many small distinctions to make (title vs metadata, label vs value, active vs inactive), and if all of them use size you end up with a dozen sizes and a noisy page. See Visual Design for hierarchy in layout; this chapter covers the typographic levers.

Emphasis by subtraction

Beginners make important things bigger and bolder. Experienced designers more often make unimportant things quieter: smaller, lighter, muted grey. The effect is the same contrast, but the page gets calmer instead of louder. A list item with a 15px semibold title and a 13px muted line of metadata has clear hierarchy without any big type.

Be careful with grey. Muted text still has to meet contrast requirements (4.5:1 for normal text under WCAG AA); “subtle” #AAA on white fails. Use one or two defined text colours (primary and secondary), not a gradient of greys. See Accessible & Inclusive for the contrast details.

Weights: fewer than you think

Two weights (regular and semibold, or regular and bold) handle most interfaces. Add medium only if your face’s regular looks thin at small sizes. Light and thin weights are for large display sizes; at 14px on a Windows laptop they disappear. Avoid “faux bold”: if you set font-weight: 600 but haven’t loaded a 600 weight, the browser smears the regular glyphs to fake it, and the result is blotchy.

Italics and emphasis

In prose, emphasis is italic (a quiet change in texture that doesn’t break the line’s colour). In UI, emphasis is weight, because italics in short labels look accidental. Underline is reserved for links on the web, and colour alone is never the only signal (some users can’t see it).

In the wild

• Apple Mail & GmailInbox lists
  Unread messages are shown mainly by weight (bold sender and subject), not by size, so read and unread rows keep the same rhythm. Weight changes state without breaking the layout.
• Stripe DashboardTables and detail views
  Detail views pair small labels with regular-weight values and muted secondary lines, building dense but calm screens from very few sizes. Overlines and muted metadata replace headings in dense UI.
• Vignelli’s NYC Subway manualUnimark, 1970
  A tightly limited palette of type sizes and one family for an entire signage system. Constraint makes a system learnable.

Space between text elements should come from a small set of related values, and space above a heading should be larger than space below it, so headings belong to what follows.

Bringhurst compares the page to music: the rhythm of lines and spaces should be steady, and departures from it should be meaningful. In print, typographers lock every line to a baseline grid so lines on facing pages align. On screens, a strict baseline grid is harder (and less valuable), but the underlying idea is essential: spacing should be systematic, and it should express relationships.

The heading proximity rule

A heading labels the content below it, so it should sit closer to that content than to the content above. A common ratio is about 2:1 (for example 32px above, 12–16px below). When the spaces are equal, the heading floats ambiguously between two sections, and users have to read it to know where it belongs. This is the Gestalt principle of proximity (see The Human Mind) applied to type.

A spacing system from your line-height

The simplest rhythm on screens: derive spacing from a base unit (commonly 4px or 8px) and keep line-heights on that unit too. If body text is 18px with line-height 1.5, a line is 27px, which doesn’t sit on a 4px grid; 18px × 1.556 ≈ 28px does. Many teams round line-heights in px to multiples of 4 for each text style (body 28, small 20, title 32, heading 40) and use spacing tokens of 4, 8, 12, 16, 24, 32, 48, 64. Then everything snaps to one invisible rhythm and nothing looks “a bit off”.

Why exact baseline grids are hard on the web

CSS centres text inside its line box: half the extra leading goes above, half below (“half-leading”), and the font’s own ascent and descent metrics add more invisible space. So the visible top of a capital letter is not at the top of the box. That is why a button label can look slightly low even when padding is “equal”, and why aligning text to an icon needs care. Tools such as Capsize compute trims from font metrics, and newer browsers support the text-box properties (text-box-trim and text-box-edge) that cut the box down to cap height and baseline. Use them for precise component alignment; don’t chase a perfect page-wide baseline grid in a complex app.

In the wild

• Material Design4dp/8dp grid
  Components and type line-heights are designed to snap to a 4dp baseline, with spacing in 8dp steps. A shared unit for type and layout keeps a huge system consistent.
• GOV.UK Design SystemSpacing scale
  Publishes a responsive spacing scale and uses consistent heading margins across thousands of pages. Rhythm can be enforced with tokens, not willpower.
• CapsizeSeek, open source
  Uses font metrics to trim the space above capitals and below the baseline, so text boxes align precisely to layout. Invisible metric space is a solvable engineering detail.

On screens, set text flush left and ragged right by default; justify only with good hyphenation and a generous measure, and let the browser balance headings and avoid stranded last words.

Justified text, with both edges straight, looks orderly in books because book typesetting engines adjust spacing across a whole paragraph, hyphenate carefully, and may even subtly adjust letter spacing. Browsers mostly do something simpler: they break lines one at a time and stretch the word spaces on each line to fill it. On narrow columns, that produces irregular gaps and sometimes “rivers”, channels of white that run down through the paragraph and pull the eye vertically.

When justification is fine

Justified text can work on screens when three conditions hold: the measure is generous (60+ characters), hyphenation is on (hyphens: auto with a correct lang attribute on the page or element), and the content is continuous reading (an e-book, a long essay) where a book-like texture is part of the experience. E-readers such as Kindle justify by default with hyphenation. For UI, docs and anything narrow or mixed with code and links, ragged right is better. WCAG’s enhanced criterion (1.4.8) lists “not justified” among its visual presentation requirements, because uneven spacing makes reading harder for some people, including many dyslexic readers.

Shaping the rag

Ragged right isn’t carefree. A good rag ripples gently; a bad one has deep notches or a staircase shape. On the web you can’t hand-tune each paragraph, but you can help: keep the measure in range, enable hyphenation for long-word languages (German, Dutch) and narrow mobile columns, and use non-breaking spaces to keep small units together (“10 MB”, “Mr. Sharma”, “Chapter 7”).

Widows, orphans and stranded words

In print, an orphan is a paragraph’s first line left alone at the bottom of a page and a widow is its last line alone at the top of the next (definitions vary between sources, which is why many people just say “stranded lines”). On the web, the everyday problem is a single short word alone on the last line of a paragraph or heading (sometimes called a “runt”). CSS now helps: text-wrap: balance evens out line lengths in short blocks like headings and captions, and text-wrap: pretty asks the browser to avoid very short last lines in paragraphs. Balance is widely supported; pretty is newer, so treat both as progressive enhancement.

Centred and right-aligned text

Centred text has two ragged edges, so every return sweep must find a new starting point. It works for short, symmetrical things (a dialog title, a two-line empty state, a poster headline) and fails for anything over about three lines. Right alignment is for numbers in tables (Chapter 13) and for labels hugging a value, not for paragraphs (in left-to-right languages).

In the wild

• KindleAmazon
  Justifies book text with hyphenation by default, and some Kindle devices and apps let readers switch to left alignment. Justification is a book convention; offering ragged is a kindness.
• GitHub, Notion, LinearDocs and issues
  All set long text flush left, ragged right, in UI-width columns. Product text is mixed (links, code, mentions); ragged handles it gracefully.
• Chrome & Safari2023–2024
  Shipped text-wrap: balance, making balanced headings a one-line fix that previously needed JavaScript libraries. Check the platform before writing a workaround.

Straight quotes, double hyphens and three dots are typewriter substitutes; real typography uses curly quotes, true apostrophes, the right dash for each job and a real ellipsis, except in code, where straight characters are correct.

Typewriters had a limited keyboard, so one key served for opening quotes, closing quotes, apostrophes, feet and inches. Computers inherited that keyboard. Butterick calls straight quotes and apostrophes the most visible sign of careless typography, because they look like what they are: a mechanical compromise. Your product’s microcopy is read millions of times. Getting these marks right costs almost nothing once you know them.

The dashes

There are three common horizontal marks and they are not interchangeable. The hyphen (-) joins words (“well-known”, “sign-in page”) and breaks words at line ends. The en dash (–), about the width of an n, marks ranges and connections: “9–5”, “Mumbai–Pune”, “pages 12–18”. The em dash, about the width of an M, marks a strong break in a sentence (shown in the figure above). Many writers overuse the em dash; in UI copy, a colon, comma or full stop is often clearer. The minus sign (−) is a fourth mark, as wide as a plus sign, for negative numbers in data: −₹1,200 lines up with +₹1,200, while a hyphen looks short and weak.

Spaces you didn’t know existed

A non-breaking space ( , U+00A0) looks like a normal space but forbids a line break, so “10 MB”, “₹ 500” (if you space it), “Fig. 3” and “iOS 18” never split across lines. A thin space (U+2009) is useful around some marks and between number groups in some locales. One space after a full stop, never two; the double space is another typewriter habit.

In source code and string files you can also simply paste the Unicode characters; modern toolchains handle UTF-8. On iOS and many keyboards, long-pressing the quote or hyphen key offers these characters.

Where straight quotes are correct

Code, terminal commands, JSON, CSS, URLs and anything a user will copy into a technical context must keep straight quotes and hyphens. A curly quote in a shell command breaks it, and an en dash in a command-line flag fails silently. In your product, turn off smart punctuation in code inputs, password fields and API key fields (on iOS, smartQuotesType = .no and smartDashesType = .no; on the web, keep such content in <code> and don’t run text transforms on it).

Other languages, other marks

Quote styles vary: German uses „low-high“ quotes, French uses «guillemets» with spaces inside, Japanese uses 「corner brackets」. Hindi text generally uses the same curly quotes as English. If you localize, don’t hard-code quote characters in templates; let translators include them in strings, or use the HTML <q> element with the CSS quotes property and a correct lang attribute.

In the wild

• Apple platformsSmart Punctuation
  iOS and macOS curl quotes and convert double hyphens as you type, with a setting to turn it off and APIs for developers to disable it per field. Make correct punctuation the default, and give technical fields an escape.
• SmartyPantsJohn Gruber, 2002
  A widely used text filter that converts straight quotes, double hyphens and triple dots into typographic punctuation, alongside Gruber’s Markdown. Automate punctuation at the content pipeline, then trust it.
• Butterick’s Practical TypographyOnline book
  Devotes short, blunt chapters to straight and curly quotes, hyphens and dashes, and the ellipsis. The cheapest upgrade to any text is correct punctuation.

Most good fonts hide several versions of their numerals and other alternates; choose tabular lining figures for data, proportional or old-style figures for prose, and use real small caps and fractions instead of fakes.

Numbers are everywhere in products: prices, dates, counts, durations, versions. Fonts usually include at least two sets of digits, and many include four, selected with OpenType features. Using the right set is one of those details that makes an interface feel engineered rather than assembled.

Tabular vs proportional

Proportional figures have individual widths (a 1 is narrow, a 0 is wide), which looks even in a sentence. Tabular figures all share one width, so digits line up in columns and a changing number (a timer, a progress counter, a stock price) doesn’t jiggle as it updates. In CSS: font-variant-numeric: tabular-nums. Fonts differ in their defaults: Inter defaults to proportional figures (tabular are one feature away), while the Google Fonts versions of Source Serif 4 and EB Garamond default to tabular. Check yours.

Numbers in tables: the rules

• Right-align numeric columns (and their headers), so units, tens and hundreds stack. Left-align text columns.
• Use the same number of decimal places down a column.
• Use tabular lining figures. Consider a slightly smaller size or muted colour for units and currency symbols.
• Format by locale. In India, ₹1,12,500 (lakh grouping); elsewhere 112,500 or 112 500 or 112.500. Use Intl.NumberFormat (web) or the platform’s formatters rather than hand-rolled commas.
• Use the minus sign (−) for negatives so they align with the plus sign and look like maths.

For a full treatment of tables and charts, see Information & Data.

Small caps, fractions and other features

OpenType features are switches inside a font. The ones worth knowing, with their CSS:

True small caps are drawn letters at about x-height with weights that match lowercase. Fake small caps, which browsers synthesize by shrinking capitals when the font lacks them, look thin and pale. If your font lacks smcp, don’t use small caps; use tracked caps at a small size instead (Chapter 14).

In the wild

• Apple Clock & StopwatchiOS
  The stopwatch uses fixed-width digits so the running time doesn’t shift left and right every hundredth of a second. Anything that ticks needs tabular figures.
• InterRasmus Andersson
  Documents features like tnum, zero (slashed zero), case-sensitive forms and several character variants, so product teams can tune numbers and ambiguous glyphs without changing fonts. Read your font’s feature list; it’s free capability.
• Financial appsZerodha Kite, Robinhood and others
  Price lists and order books rely on aligned figures and right alignment so users can scan changes quickly. In data-heavy products, figure style is a usability feature.

Fonts are spaced for lowercase text at one size range; capitals, very small text and very large text all need spacing adjustments, and optical sizes and variable fonts let the font itself adapt.

A type designer spends as long on spacing as on shapes. The spacing is tuned for lowercase text around reading sizes. Move away from that sweet spot and the spacing stops fitting. Two adjustments fix it: tracking (uniform letter-spacing across a run of text, letter-spacing in CSS) and kerning (adjustments between specific pairs like “AV” or “To”, built into the font and on by default in browsers).

The three tracking rules

1. All caps and small caps: add tracking. Capitals are designed to sit next to lowercase, so in a row of capitals they crowd. Butterick suggests 5–12% extra; in CSS, letter-spacing: 0.05em to 0.12em. The smaller the caps, the more they need.
2. Large display text: reduce tracking slightly. At 40px and above, default spacing looks loose. Try −0.01em to −0.03em. Never so tight that letters touch.
3. Small text: add a touch. Below about 13px, a hair of extra spacing (0.01–0.02em) helps letters stay distinct. Apple’s SF does this automatically by size.

Never track lowercase body text for “style”: it breaks up word shapes and slows reading. And note a CSS detail: when you add letter-spacing, browsers turn off optional ligatures, which is what you want for spaced caps.

Optical sizes

In metal type, each size was cut separately: small sizes had larger x-heights, sturdier hairlines, looser spacing; large sizes were finer and tighter. Digital fonts lost that when one outline was scaled to every size. Optical sizes bring it back. Some families ship separate cuts (SF Pro Text and SF Pro Display; Inter and Inter Display), and variable fonts can have an opsz axis that the browser sets automatically from the font size (font-optical-sizing: auto, the default). This page’s body text, Source Serif 4, has an opsz axis: the headings and body you are reading are slightly different designs.

Variable fonts

A variable font is one file containing a continuous design space along axes. The registered axes are weight (wght), width (wdth), optical size (opsz), italic (ital) and slant (slnt); fonts may add custom ones, such as grade (GRAD), which changes weight without changing width. For a product this means: one file instead of six, any weight you like (550 if 500 is too light and 600 too heavy), automatic optical sizing, and tricks like adjusting grade in dark mode (Chapter 18). Use font-weight, font-stretch and font-optical-sizing when possible; drop to font-variation-settings only for custom axes.

In the wild

• SF ProApple, 2015 onward
  Apple’s system applies size-specific tracking and switches optical designs (Text below about 20pt, Display above), so developers rarely touch letter-spacing. The best tracking is the kind the system does for you.
• Inter 42023
  Added an optical-size axis and Inter Display, so headings get tighter, finer forms automatically. Open-source fonts now offer what used to need premium families.
• Roboto FlexGoogle, 2022
  A variable font with many axes including weight, width, optical size and grade. Grade lets you change weight for contrast without reflowing text.

Interface text is short, functional and unpredictable in length; design it to be scannable at small sizes, to wrap or truncate gracefully, and to grow when the user asks for bigger text.

Reading typography optimizes a paragraph you control. UI typography handles hundreds of tiny strings you don’t: a user’s name that might be “Li” or “Venkatanarasimharajuvaripeta”, a translated button label 40% longer than English, a price with seven digits, a user who has set their phone to the largest text size. The craft here is less about beauty and more about resilience.

Labels, buttons and captions

• Labels sit close to what they label (proximity), in a quieter style than the value: smaller or muted, rarely both. Sentence case reads fastest.
• Buttons use a verb, sentence or title case, and medium or semibold weight at body size or slightly smaller. Keep the label visually centred (mind the invisible line box from Chapter 10) and give it padding in em so it grows with text.
• Captions and helper text are the smallest size in your scale, but not below 12px on the web (Apple’s smallest style is 11pt) and with enough contrast to read.
• Numbers in UI are often the most important element on a screen (a balance, a count, a temperature). Let them be the largest text, in tabular figures, with units smaller and muted.

Wrapping vs truncation

When text is longer than its space, you have three options: wrap it, truncate it, or let it overflow (never). The default should be wrap: it keeps all the information and adapts to translations and large text. Truncate only where a fixed height matters for scanning (list rows, tabs, table cells), and then:

• Truncate at the end for titles and names (“Quarterly planning for the…”), using an ellipsis, and give the full text on hover, focus, or the detail view.
• Truncate in the middle for file names and paths, where the end carries meaning (“Invoice_2026…final_v3.pdf”), as macOS Finder does.
• Clamp multi-line previews (-webkit-line-clamp / line-clamp) to two or three lines, not one.
• Never truncate numbers, prices, dates or anything a user must compare or act on.

Dynamic Type and user font sizes

Many people enlarge text: on iOS through Dynamic Type (from the default “Large”, where Body is 17pt, up through accessibility sizes where Body reaches about 53pt), on Android with the font scale setting, on the web with browser zoom and default font size. WCAG requires that text can be resized to 200% without loss of content or function. Your layout must survive. That means: sizes in relative units (rem on the web, text styles on native), no fixed heights on text containers, buttons that grow, rows that wrap, and layouts that switch from horizontal to vertical when text gets big (iOS apps commonly stack label and value at accessibility sizes).

Minimum sizes

Practical floors: 16px for body text and form inputs on the web (iOS Safari zooms the page when focusing an input under 16px, which annoys users), 12–13px for secondary UI text, 11pt as Apple’s smallest system style. Below those, use them only for non-essential, decorative or legal-fine-print text, and even then, with sufficient contrast.

In the wild

• iOS SettingsApple
  At accessibility text sizes, rows stack the label above the value and grow vertically rather than truncating. The layout itself changes shape as type grows.
• macOS FinderApple
  Truncates long file names in the middle, keeping the start and the extension visible. Truncate where the information isn’t.
• TweetieLoren Brichter, 2008
  Set tweet text, names and metadata with clear weight and colour steps in fast-scrolling rows, a pattern most timeline apps followed. Scannable rows come from consistent roles, not decoration.

The same font looks different on macOS, Windows and Android, and it may arrive late or not at all; test on real platforms and load fonts so text is readable immediately and doesn’t jump when the font arrives.

Why your font looks different on Windows

Text rendering turns ideal outlines into pixels, and platforms make different trade-offs. macOS has long favoured fidelity to the outline shape, which looks smooth and slightly heavier and blurrier; since macOS Mojave (2018) it no longer uses subpixel antialiasing by default, so text on non-Retina Mac screens looks lighter than it used to. Windows, with ClearType and DirectWrite, has favoured snapping strokes to the pixel grid for sharpness, which relies more on hinting (instructions in the font that tell the rasterizer how to fit the grid). A font with poor hinting can look crisp on a Mac and ragged or thin on a Windows laptop. On high-density screens (2x and above) these differences shrink a lot; on the 1x office monitors many people still use, they matter.

A CSS note: -webkit-font-smoothing: antialiased only affects macOS browsers, making text look lighter. Many sites set it globally; it can help light text on dark backgrounds, but on a light background it often makes body text too thin. Use it deliberately, not by habit.

Font loading: FOIT, FOUT and layout shift

Web fonts download after the page starts rendering. Browsers then choose between two failure modes. FOIT (flash of invisible text): text is hidden until the font arrives, typically for up to about three seconds, and on a slow connection users stare at a blank page. FOUT (flash of unstyled text): text shows in a fallback font immediately and swaps when the web font loads, which may shift the layout. You control this with font-display in @font-face:

A loading recipe

1. Self-host WOFF2 files from your own domain (fast, private, no third-party dependency).
2. Subset to the characters and scripts you need (with unicode-range so other scripts load only on demand), but keep the OpenType features you use.
3. Use one variable file instead of many static weights where you can.
4. Preload the one or two files needed above the fold: <link rel="preload" as="font" type="font/woff2" crossorigin>.
5. Set font-display: swap (or optional) and define a fallback @font-face that uses a local font with size-adjust, ascent-override and descent-override so its metrics match. Several frameworks (for example Next.js’s font tooling) generate these for you.

In the wild

• Verdana & GeorgiaMatthew Carter and Tom Rickner, 1996
  Drawn with the pixel grid in mind and extensively hand-hinted, they stayed crisp on low-resolution Windows screens for decades. Rendering is part of type design.
• Google Fonts APIfont-display parameter
  The CSS API accepts display=swap (as this page uses) and serves subsetted WOFF2 files split by unicode-range. Even if you self-host, copy its subsetting strategy.
• Next.js next/fontVercel
  Self-hosts fonts at build time and generates a size-adjusted fallback to reduce layout shift. Framework tooling can automate the hard part of loading.

Other scripts have different shapes, heights and rules; give them fonts designed for them, enough line height for their marks, and sizes matched by eye to your Latin text.

If your product might be used in India, Hindi, Marathi, Bengali, Tamil, Telugu and other Indian languages are not an edge case. Even an English-first app shows Indian names, addresses and user-generated text. The Latin rules in this guide don’t transfer automatically. Devanagari, used for Hindi, Marathi, Nepali and Sanskrit, is a good example of why.

How Devanagari differs

• The headline (shirorekha). Most letters hang from a horizontal line at the top, which joins letters into words. Visually, the “x-height” is the body between the headline and the baseline.
• Marks above and below. Vowel signs (matras) and other marks sit above the headline and below the baseline, and conjuncts stack. That needs more vertical room than Latin: line-height around 1.6–1.8 for body text, versus 1.4–1.6 for Latin.
• Apparent size. At the same font-size, Devanagari often looks smaller than Latin because the main body is a smaller fraction of the em. It commonly needs a slightly larger size (often 10–15% more) to feel equal.
• Shaping. Letters change form in combination (conjuncts, reordering of vowel signs). This requires proper OpenType shaping, which modern browsers and OSes do, but which breaks if you letter-space, fake bold or cut strings in the middle of a grapheme cluster.
• No case. There are no capitals, so all-caps styling and tracking rules don’t apply; use weight and size for hierarchy.

The Hindi sample reads: “Your order has been sent. You can see the delivery status on the order page, and contact us if there is a mistake in the address.”

Fonts for Indian scripts

Use a font designed for the script, not whatever the system falls back to. Good free options: the Noto families (Noto Sans Devanagari, Noto Serif Devanagari, and Noto for Bengali, Tamil, Telugu, Kannada, Malayalam, Gujarati, Gurmukhi and Odia), which aim at broad, consistent coverage; Hind and other families from Indian Type Foundry; Mukta from Ek Type; and IBM Plex Sans Devanagari, which matches IBM Plex Sans. Many of these were designed alongside a Latin companion, so the two scripts sit together well.

Mixed scripts on one screen

When a user’s Hindi name appears in an English UI, or an English brand name appears in Hindi text, two fonts share a line. Make it work by: listing a script-specific font in the stack (CSS picks per character, so font-family: Inter, "Noto Sans Devanagari", sans-serif uses Inter for Latin and Noto for Devanagari); setting lang attributes on content in other languages (this drives font selection, hyphenation and screen reader pronunciation); sizing so both scripts look the same size; and setting line-height for the taller script wherever it might appear.

Localization beyond Indian scripts

• Expansion: translated strings are often 30% longer or more (German, Finnish); short English labels can double. Wrap, don’t clip (Chapter 15).
• CJK: Chinese, Japanese and Korean text has no word spaces, wraps between most characters, needs larger fonts (fonts are big files; rely on system fonts or careful subsetting), and has its own punctuation rules. WCAG’s line-length guidance is 40 characters for CJK versus 80 for Latin.
• Right-to-left: Arabic and Hebrew mirror layouts; use logical CSS properties (margin-inline-start, text-align: start) so your layout flips correctly.
• Numerals and formatting: dates, numbers and currency vary by locale; always use locale-aware formatters.

In the wild

• NotoGoogle
  A project to cover all scripts in Unicode with harmonized designs, named for avoiding “tofu” (the empty boxes shown for missing glyphs). Coverage is a typographic responsibility.
• Indian Type Foundry & Ek TypeIndia
  Released many free, multi-script families (Hind, Mukta and others) through Google Fonts, designed by people who read the scripts daily. Prefer fonts made by native readers of the script.
• Government and banking apps in IndiaUPI era
  Many offer Hindi and regional-language interfaces, where tight Latin-style line-heights are a common source of clipped matras. Test vertical clipping in every script you ship.

Code needs a monospace with unmistakable characters set slightly smaller than body text; dark mode needs slightly lighter weights and softer contrast, because light text on dark looks bolder and glows.

Choosing a code font

In code, every character carries meaning and readers scan vertically for alignment, so monospace (every glyph the same width) is the norm. What separates a good code font: distinct 0 O, 1 l I, and { } ( ) [ ]; punctuation big enough to see (a comma vs a full stop matters); a generous x-height; and enough weight to survive dark themes. Good choices include SF Mono and Menlo (Apple), Consolas and Cascadia Code (Microsoft), JetBrains Mono, IBM Plex Mono, Fira Code and Source Code Pro. For a web stack, ui-monospace, "SF Mono", Menlo, Consolas, monospace gives a good native mono on each platform, as this course uses.

Setting code

• Size it down. Monospace looks bigger than proportional text at the same size because it is wider. Inline code usually sits at 0.85–0.9em of the surrounding text (this page uses 0.86em).
• Leading 1.5–1.6 for code blocks; tight code is hard to scan.
• Don’t wrap code by default in blocks; scroll horizontally, and keep lines short in examples you write.
• Ligatures are a choice. Programming ligatures (Fira Code, JetBrains Mono, Cascadia Code) turn != or => into single symbols. Some developers love them; Butterick argued against them in an essay because they can misrepresent the actual characters. In a product that shows code to others, leave them off; in an editor, make them a setting.

const total = items
  .filter(i => i.qty > 0)
  .reduce((s, i) => s + i.price * i.qty, 0);
if (total !== 0) log(`Total: ${total}`);

Monospace for writing

iA Writer made a deliberate, debated choice: a monospace-derived face for prose writing. The argument is that monospace slows the eye slightly and makes the text feel like a draft, which encourages writing rather than admiring. iA later designed Duo (a few wide letters like m and w get extra width) and Quattro (closer to proportional) to keep that “draft” feel while reducing monospace’s gappy texture. The lesson for your product isn’t “use monospace”; it is that a font’s texture changes how people feel about the act they perform. Choose texture for the job.

Type in dark mode

Light text on a dark background looks heavier and slightly blurred than the same text dark-on-light. Part of this is perceptual (bright areas appear to spread into dark ones, an effect often called irradiation), part is rendering, and for people with astigmatism very bright text on black can appear to glow or smear (halation). Three adjustments help:

1. Soften the extremes. Avoid pure white (#FFF) on pure black (#000). Off-white on a very dark grey keeps contrast well above 4.5:1 while reducing glare.
2. Lighten weight slightly. If body text is 400 in light mode, it can look like 450 in dark mode. Variable fonts with a grade axis let you reduce apparent weight without changing width; otherwise consider one step lighter for large text, and check thin weights don’t disappear.
3. Re-check muted text. Secondary greys tuned for light mode often fail or look muddy in dark mode. Define them separately (this course defines every colour token twice).

In the wild

• iA WriterMono, Duo, Quattro
  Offers three related faces so writers can choose how “draft-like” the text feels, and publishes them under an open licence. Texture is a product decision.
• JetBrains MonoJetBrains, 2020
  A code font with a tall x-height and distinct glyphs, designed for long reading sessions in an IDE, with optional ligatures. Code fonts are reading fonts for a specific kind of text.
• Apple’s dark modemacOS Mojave, iOS 13
  Uses near-black and dark grey backgrounds with off-white and grey label colours, rather than pure white on pure black. Even the platform tones down contrast for comfort.

Good typography is a sequence of small, ordered decisions; applied in the right order, six steps turn default text into a calm, professional page.

Below is a short article as it might appear in a product changelog or blog, first with browser-ish defaults and no decisions. Step through it. Each step applies one chapter and changes only what that chapter controls. Notice that the biggest improvements come early (size, leading, measure) and the later ones are refinements. That ordering is the practical lesson: when time is short, do steps 1 and 2 first.

What each step did, and why in this order

1. Body (Chapter 7). A screen serif at 18px, line-height 1.6, paragraph spacing instead of nothing. Every line in the article improved at once.
2. Measure (Chapter 7). The body column capped at about 34em, roughly 65–75 characters on desktop. Return sweeps became reliable.
3. Scale (Chapter 8). Title and subheading set from a scale, in the sans, with tighter leading and slight negative tracking on the title.
4. Rhythm (Chapter 10). More space above the subheading than below; title separated from the body. Sections now group visually.
5. Hierarchy (Chapter 9). The kicker became a tracked overline; metadata became smaller, muted sans. The title is now unambiguously first.
6. Details (Chapters 11–13). Curly quotes and apostrophe, an en dash for the range, a real ellipsis, balanced headings, pretty paragraph wrapping and tabular figures in the metadata.

In the wild

• Reader modesSafari, Firefox, Edge
  Apply roughly steps 1–4 automatically to any page: a readable size, generous leading, a narrow column, and clean spacing. The first four steps are so valuable browsers ship them as a feature.
• Ghost & SubstackPublishing platforms
  Default article templates already have a comfortable body size, measure and heading scale, which is a large part of why writers choose them. Good defaults are a product advantage.
• MediumEarly 2010s
  Built its reputation partly on how good plain text looked by default: large serif body, narrow column, calm metadata. Typography can be the product’s first impression.

Wrap-up

Practice assignment for the next two weeks

Typography improves with daily looking and weekly doing. Spend about 20 minutes a day.

1. Days 1–3: See. Each day, screenshot one screen from an app you admire and one you don’t. Annotate size, leading, measure, scale steps, weights and one detail (quotes, figures, tracking). Use this guide’s vocabulary.
2. Days 4–5: Decide. Write your type decision record (Exercise 5.1) and set body tokens (Exercise 7.1).
3. Days 6–8: Systematize. Collapse your sizes into a named scale (8.1), fix spacing (10.1) and hierarchy (9.1).
4. Days 9–10: Detail. Punctuation sweep (12.1), number audit (13.1), tracking tokens (14.1).
5. Days 11–13: Harden. Stress fixtures at 200% (15.1), loading and Windows check (16.1), script test (17.1), dark mode pass (18.1).
6. Day 14: Show. Run the six-step worked example on your longest screen (19.1), complete the type audit checklist, and put a before/after strip somewhere you’ll see it.

Reading list

• The Elements of Typographic Style
  Robert Bringhurst (1992, later editions) · The classic on text typography: measure, rhythm, scale, details. Print-oriented but the principles transfer.
• Butterick’s Practical Typography
  Matthew Butterick (free online) · Blunt, practical rules with numbers; the fastest way to fix everyday text. Read the summary page first.
• Stop Stealing Sheep & Find Out How Type Works
  Erik Spiekermann and E. M. Ginger · A friendly, visual introduction to seeing and choosing type.
• Thinking with Type
  Ellen Lupton · Letter, text, grid, with many visual examples; good for building vocabulary.
• On Web Typography
  Jason Santa Maria (A Book Apart, 2014) · Choosing and pairing type for screens, with a designer’s eye.
• Web Typography
  Richard Rutter (2017) · Detailed, technical guide to setting type with CSS, from measure to OpenType features.
• “Web Design is 95% Typography”
  Oliver Reichenstein, Information Architects (2006) · The short essay that frames this whole guide.
• “The Crystal Goblet”
  Beatrice Warde (1930 lecture) · Why type in the service of reading should be invisible.
• “The Science of Word Recognition”
  Kevin Larson, Microsoft (2004) · The readable research review behind Chapter 4’s word-shape discussion.
• “More Meaningful Typography”
  Tim Brown, A List Apart (2011) · The article that brought modular scales to web design.
• Typeface Mechanics series
  Tobias Frere-Jones (essays on his studio’s site) · How type designers solve overshoot, spacing and other optical problems.
• Apple Human Interface Guidelines: Typography, and Material Design 3: Typography
  Apple; Google · The platform rules for text styles, sizes and dynamic type you’ll build against.

Next, Reading & Writing applies everything here to calm tools for long-form reading and focused writing, and Accessible & Inclusive goes deeper on contrast and text scaling.