Pairing fonts when you're not a designer.

Most developers don't pick bad fonts. They pick fonts the way they pick variable names — whatever felt right in the moment, one screen at a time — and two features later there are three typefaces on the page with no rule for which does what. Here's a system that doesn't require a design background, just a few constraints applied consistently.

Two fonts, not five

The instinct when something looks flat is to add more typefaces, not fewer. It goes the other way. One font for headlines and UI chrome, one for body and supporting text, covers almost every screen an app or a listing needs. A third is fine for a genuinely separate register — a monospace for numbers, code, or timestamps — but it's a third voice, not a decoration, and it should only show up where that register actually applies.

If you're reaching for a fourth typeface to fix a page that still looks off, the problem usually isn't a missing font. It's that the first two aren't doing their jobs.

Pair by contrast, not by taste

The most common pairing mistake is picking two fonts that are almost the same — two clean geometric sans-serifs, say, that differ only in the shape of a lowercase "a." Side by side they don't complement each other, they compete, and the page reads like an inconsistency rather than a choice. Nobody consciously notices "these are two different fonts," they just register that something feels slightly wrong.

Real pairing works by contrast that's obvious enough to read as deliberate: a geometric display face against a workhorse text sans, or a serif with real personality against a neutral grotesk. The two fonts should look like they're doing different jobs, because they are — one is for a glance, the other is for reading.

Let one family do both jobs

The lowest-risk pairing isn't a pairing at all — it's one type family used at two extremes of its own weight range. A 700-weight cut for headlines, a 400-weight cut of the same font for body copy, maybe an italic for emphasis. Same skeleton, same spacing rules, same character shapes, so nothing can clash. Most variable fonts ship a wide enough weight range that this covers more ground than people expect, and it's one fewer font file to load.

This site's own type stack is a version of that logic with a twist: Instrument Serif carries the display headlines, Inter Tight handles body copy and UI labels, and JetBrains Mono shows up only for the handful of places that need a technical, fixed-width feel. Two clearly different registers, each with exactly one job, plus a narrow third for a narrow purpose.

Test at the size it'll actually ship at

A headline font that looks striking at 96px in a design tool can turn illegible at 14px in a button label, and the reverse trap is just as common: fonts built for small-size legibility — tall x-height, open counters, wide spacing — often look thin and characterless blown up to hero size on a screenshot. A pairing has to be judged in the two places it will actually appear, not in the abstract.

For an App Store screenshot specifically, that means checking your headline font at the size it renders in the carousel thumbnail — small, at arm's length — not just at full-bleed on your monitor. A font that only works at monitor scale isn't shipping-ready.

A few starting points

If you want combinations that are known to hold up rather than guessing from scratch: a geometric sans headline (Poppins, Montserrat, Space Grotesk) against a neutral text sans (Inter, DM Sans) reads as friendly-but-clean and works for most consumer apps. A display serif headline against a grotesk body reads as more premium or editorial — good for anything selling craft or trust rather than speed. What doesn't tend to work: two rounded, friendly sans-serifs together (they blur into one), or a display serif paired with another serif (too much competing texture).

ShotCanvas's own screenshot templates default to this same logic — Inter for the app's own interface chrome, and five headline fonts (Poppins, Montserrat, Space Grotesk, DM Sans, Outfit) you can pair against it inside a design, each picked because it contrasts cleanly with Inter rather than blending into it.

One pairing, everywhere

A pairing that only lives in the app is doing half its job. The same headline/body split should show up in the App Store screenshots, on the marketing site, in onboarding emails, and on the icon if there's any lettering on it at all. This is the part teams skip because it spans several tools — the app is built in one place, screenshots in another, the website in a third — and nobody owns the whole surface at once.

The payoff is bigger than it sounds. A visitor who sees the same headline font on your screenshot, your listing description card, and the app itself thirty seconds later gets a small, wordless signal that this is one coherent product and not three contractors' worth of loosely connected screens. Inconsistency reads as amateur even when every individual screen looks fine; consistency reads as intentional even when the pairing itself is a safe, boring choice. If you only have time to fix one thing, fix the drift between surfaces before you fix the pairing itself.

Stop before it's perfect

Type pairing has real diminishing returns past a certain point. The gap between a good pairing and a "perfect" one, after another hour of swapping fonts, is smaller than the gap between a good pairing and the flat, inconsistent page you started with. Pick a contrast-based pair, apply it consistently across every screen and every screenshot in the set, and ship it. A consistent system beats an optimal font you're still auditioning.