Font pairing starts with reading tasks
A useful font pairing assigns complementary roles to typefaces while keeping the interface readable and coherent. The objective is not to maximize contrast between two fonts. It is to help people distinguish headings, body content, controls, and data without making the product feel fragmented.
TDP’s font-pairing article emphasizes context and contrast. Treat its pairings as historical examples, then test your actual content, language coverage, and implementation needs. A pairing that works for a large editorial headline may be unsuitable for a dense settings screen.
Start with the body and interface roles. Add a second family only if it contributes something the first cannot provide through size, weight, or spacing.
Step 1. Define the jobs the fonts will do
Separate display text from task-focused text. A landing-page headline can carry more personality than a transaction table or dense settings form. Decide which parts of the product need expression and which need fast, repeated reading. Write these roles down before comparing visual styles.
Step 2. Build one realistic specimen
Use a heading, a paragraph, an input label, an error message, a price, and a table row. Include similar-looking characters such as I, l, and 1. Compare the same specimen for each candidate. An attractive alphabet sample cannot show whether a font handles long product names or a narrow mobile layout.
Step 3. Compare a small shortlist
Try one family with different weights, then a deliberate two-family pairing. These are starting directions to inspect in the font provider’s live specimens; the best choice depends on your product.
| Direction | Candidate to investigate | Check closely |
|---|---|---|
| One-family UI | DM Sans in regular and medium/bold roles | Small labels, numbers, hierarchy |
| Editorial display + UI text | DM Serif Display with DM Sans | Heading proportions and dense body content |
| Related serif/sans families | Source Serif 4 with Source Sans 3 | Whether both families add a useful distinction |
Step 4. Write the implementation specification
Record family, weight, size, line height, fallback, and purpose for every text role. Do not ask the browser to invent a weight you did not provide. Confirm the provider’s current license and language coverage, and include loading behavior in engineering review.
/* Substitute the verified font files and families you ship. */
.body-copy { font-family: var(--font-body), sans-serif;
font-size: 1rem; line-height: 1.5; font-weight: 400; }
.section-title { font-family: var(--font-heading), sans-serif;
font-size: 2rem; line-height: 1.2; font-weight: 600; }
Step 5. Test the pair in use
Compare the specimen at narrow and wide widths. Increase text size, test a long translation, and inspect what happens while fonts load. If adding a second family makes the interface harder to scan or maintain, keep the single-family option. Document the decision with the specimen, not just the font names.
Worked example: evaluate a display face beside an interface face
Imagine a product needs expressive onboarding headlines and a dense administration area. Test the display candidate on a real onboarding sentence, including a long version. Test the interface candidate on labels, helper text, a table row, and an error. Then place them on the same screen.
Compare the relationship at actual sizes. Similar nominal font sizes can look different because of letter proportions and x-height. A display face can overpower nearby controls even when its size seems modest. Adjust the hierarchy through the roles rather than forcing both families to share every value.
| Specimen | What to inspect |
|---|---|
| Long heading | Wrapping, rhythm, and emphasis |
| Body paragraph | Sustained reading and line length |
| Field label and hint | Distinction without excessive weight changes |
| Table data | Alignment, number clarity, and dense scanning |
| Error message | Readability when space is constrained |
| Localized content | Required characters and realistic text expansion |
Compare three options, including one family
Build the same specimen with one family, a related serif/sans pairing, and a more contrasting pairing if the brand calls for it. Keep the content and layout consistent so the comparison reflects typography rather than unrelated design changes.
Ask which version makes the hierarchy easiest to follow and which fits the product’s intended voice. Avoid declaring one family universally “trustworthy” or “modern.” Those judgments depend on the specific typeface, composition, and audience.
Verify the files you will actually ship
Confirm that the required weights, styles, and characters are available in the chosen font files and that your intended use is permitted. A design file can show a weight that the website never loads. Synthetic bold or a fallback font can change the result.
Test the interface before and after the font loads. Long labels and headings should remain usable if the preferred font is delayed or unavailable. Performance and fallback behavior are part of the type decision, not an engineering detail to leave until after approval.
Document the pairing by role
Write down which family belongs to display headings, body text, controls, data, and code examples. Name the allowed weights and any exceptions. Do not leave consumers to choose between two families based on personal preference for each screen.
If the second family adds little value, remove it. A single well-used family can produce a clear hierarchy and simplify maintenance. The type-scale guide explains how to turn the chosen family into named text roles.
Review the pairing with real users and content
Preference feedback can reveal brand fit, but it does not establish readability. Ask people to find information, interpret a form, or compare a table. Observe wrapping and scanning problems at narrow widths and with zoom.
Record why the chosen pairing works and where it should not be used. That rationale helps the next designer extend the system without reopening the whole decision. Use the serif versus sans-serif guide when the category choice is still unresolved.
Completion checklist
- Each family has a defined role.
- The actual font files support the chosen weights and characters.
- Long labels and numbers remain readable.
- Fallback fonts preserve a usable layout.
- Licensing and loading decisions are recorded.
Common questions
Do two contrasting fonts automatically make a good pairing?
No. Contrast should support hierarchy and the product’s tone. Compare proportions, spacing, and readability in the interface.
Is 16px always the correct body size?
It is a useful starting example for many web interfaces, not a universal requirement. Test the actual font, content, device, and audience.
Sources and TDP resources
- Google Fonts: pairing typefaces
- Google Fonts directory for current specimens, supported languages, and licenses.
- TDP’s original Google font pairing article