Where do these pairings come from — are they AI-generated?

No. Every pair in the library is sourced from a real design system or a credible typographer's recommendation: Medium uses Charter + Source Sans, Stripe uses Inter + Inter, Apple Newsroom pairs SF Pro Display + SF Pro Text, The New York Times pairs Cheltenham + Imperial, Vercel uses Geist + Geist Mono, and so on. The classic editorial pairs (Playfair Display + Source Sans, Lora + Open Sans, Cormorant + Montserrat) come from Typewolf, Fonts In Use, and the Google Fonts "popular pairings" research. We swap any non-Google font for its closest open-source equivalent so every pair loads for free, but the pairing logic — which typeface families have been proven to work side-by-side at scale — is human, not generated.

How do I actually use a pair on my site?

Click "Copy CSS" on any pair. You get two things — the Google Fonts `@import` URL (paste at the top of your stylesheet) and the body / heading CSS rules (paste anywhere in your stylesheet). For React or Next.js, the same `@import` works in a global stylesheet, or you can swap it for `next/font/google` with the two family names. For Tailwind, drop the two families into `tailwind.config.js` under `theme.fontFamily.sans` and `theme.fontFamily.serif` (or `display` and `body`), then use `font-display` and `font-body` utility classes. Performance tip — if you only use 1-2 weights per family, narrow the `@import` URL to `wght@400;700` instead of pulling every weight; the generated CSS already does this.

Why pair a serif heading with a sans-serif body (or vice versa)?

Visual contrast. A page set entirely in one typeface — even a beautiful one — reads as monotonous: heading and body blur together, scanning becomes harder. Pairing a serif (Playfair, Cormorant, Lora) for the heading with a sans-serif (Source Sans, Inter, Open Sans) for body copy gives the heading visual weight and personality while keeping body text crisp and screen-readable at small sizes. The reverse — sans heading, serif body — works for editorial / long-form reading (Medium, Substack, The New Yorker all use this pattern). Pure serif-on-serif or sans-on-sans pairings are also fine, but require deliberate contrast in weight (e.g., Inter Black heading + Inter Regular body) or in family character to avoid mush.

Do these pairings work for Chinese / Japanese / Korean sites?

The 4 CJK pairs in the library do — Source Han Serif (思源宋体) paired with Source Han Sans (思源黑体) is the de-facto standard for bilingual sites and editorial CJK content (used by 知乎, Medium 中文, the Adobe / Google joint open-source release). ZCOOL KuaiLe (站酷快乐体) paired with Source Han Sans gives a playful display + clean body combo for marketing pages. For the non-CJK pairs, Latin headings will display correctly but any Chinese text in the body will fall back to the system CJK font — pair them with an explicit CJK font in your stack (`font-family: 'Inter', 'PingFang SC', sans-serif`) to keep rendering predictable across Mac, Windows, and Linux.

Why "@import" instead of " " — isn't @import slower?

For maximum performance you should use ` ` plus ` ` in ` ` — that's what the Google Fonts docs recommend. We show `@import` in the copy-to-clipboard output because it's the most portable: works in plain CSS files, CSS-in-JS, Tailwind global CSS, Astro / Next.js global stylesheets, and CodePen demos. For a production landing page, take the Google Fonts URL from the `@import` line and rewrite it as two ` ` tags in your HTML ` ` (one `preconnect` to `fonts.googleapis.com`, one `stylesheet` to the actual `css2?family=...` URL) — that's the fastest setup, but it requires HTML access. The CSS we generate is the universal fallback.

Killing the system-ui placeholder before a landing-page launch

You shipped a marketing page on `font-family: system-ui` to hit a deadline, and it reads like an unfinished admin panel. Filter to the modern + brand pairs, find Inter Display heading over Inter body or Geist over Geist Mono, copy the two CSS rules plus the `@import`, and the page suddenly looks art-directed in under five minutes without you opening a single font catalogue.

Picking a serif-on-sans pair for a long-form blog

You write 1,500-word essays and want them to read like Substack, not a wiki. Switch the sample text to one of your real paragraphs, flip through the editorial pairs (Lora + Open Sans, Source Serif + Source Sans), and judge each at the 16px body size you actually ship. You commit the winner once instead of A/B-ing five fonts live on readers.

Building a bilingual zh/en site that renders the same everywhere

Your product page mixes English headings with Chinese body copy and falls back to ugly system CJK on Windows. Open the 4 CJK pairs, take Source Han Serif + Source Han Sans, and the generated CSS gives you an explicit CJK stack so 知乎-grade typography shows up identically on Mac, Windows, and Linux instead of three different renderings.

Handing a dev a copy-paste spec instead of a Figma screenshot

You are the designer; the engineer wants exact font names, not a PNG. Lock the pair you chose, copy the CSS block (the `@import` URL, the `h1` rule, the `body` rule, weights already narrowed to `wght@400;700`), and drop it in the ticket. No back-and-forth over which Playfair weight or whether it was Montserrat 500 or 600.

Font Pairing Generator — 50+ Curated Google Fonts Combinations

Font pairing generator — 50+ curated Google Fonts pairs (heading + body) with live preview, classifications, CSS export.

Runs locally
Category Color & Design
Best for Moving from a visual idea to reusable color values.

Search by font name, style, or use case…

Style

Use case

Sample heading

Sample body

56 pairsDark preview