Times New Roman shows up everywhere résumés, legal docs, academic papers and plenty of site owners still want to use it on the web. The problem? It's a system font that wasn't designed for screens, and pairing it with the wrong typeface can make a responsive layout look dated or broken at different screen sizes. Choosing the right Google Fonts that pair with Times New Roman for responsive layouts helps you keep that classic feel while making sure your text stays readable on phones, tablets, and desktops alike.

Why would someone use Times New Roman on a website?

Times New Roman carries a sense of formality and trust. Law firms, academic publishers, and news outlets sometimes lean on it for that reason. It's available on virtually every operating system, which means it loads instantly with no extra HTTP requests. The trade-off is that it renders inconsistently across devices it looks sharp on Windows but thinner on macOS, and it can feel cramped at small sizes on mobile. That's where a well-chosen Google Font companion comes in: it balances the formality of Times New Roman with better screen rendering and more flexible sizing.

What makes a font pairing work in a responsive layout?

A responsive font pairing needs to hold up when the layout shifts from a wide desktop screen to a narrow mobile viewport. Here's what to check:

Contrast without conflict. The two fonts should be different enough to create visual hierarchy usually a serif with a sans-serif but share similar proportions or x-heights so they don't fight each other.
Legibility at small sizes. The companion font should remain crisp below 16px on mobile. If it blurs or clumps at body-text size, it's a poor match for responsive work.
Flexible weight range. Fonts with multiple weights (400, 500, 700) give you more control over hierarchy without changing font families mid-page.
Similar mood and era. A neo-grotesque sans-serif next to a traditional serif like Times New Roman usually works better than a playful display font.

For a deeper look at how serif and sans-serif combinations work on web pages, see our breakdown of serif and sans-serif font combinations for web pages.

Which Google Fonts pair well with Times New Roman?

Below are proven pairings. In each case, Times New Roman stays in the role it fits best often as the heading font or the body font depending on context while the Google Font handles the other job and loads reliably on every device.

Open Sans + Times New Roman

Open Sans is one of the most readable sans-serifs on screens. Its generous x-height and open letterforms contrast with the tighter structure of Times New Roman without clashing. Use Times New Roman for headings and Open Sans for body text at 16–18px. This pairing works well for editorial sites and professional services where a formal tone still needs to feel approachable.

Roboto + Times New Roman

Roboto's geometric skeleton and neutral personality make it a flexible partner. It holds up at very small sizes, which is useful for mobile navigation, captions, and UI labels. Pair Times New Roman in article headings with Roboto at 15–16px for body text. The slight mechanical quality of Roboto gives the layout a modern edge that offsets the old-fashioned serif.

Montserrat + Times New Roman

Montserrat has a geometric, slightly condensed shape that draws a clear contrast with the narrow letterforms of Times New Roman. This pairing suits hero sections and landing pages where you want bold, clean headings in Montserrat and long-form reading text in Times New Roman. Keep Montserrat at font-weight 600 or 700 for headings to avoid it looking too thin next to the heavier serif.

Merriweather + Times New Roman

If you want to stay in the serif family, Merriweather is a screen-first serif that was specifically designed for body text. Its wider letter spacing and sturdier strokes solve many of the legibility issues Times New Roman has at small screen sizes. Use Times New Roman for display headings at 28px+ and Merriweather for reading text at 16–18px. Both are serifs, so the mood stays cohesive.

Source Sans Pro + Times New Roman

Adobe's Source Sans Pro is clean, professional, and has a slightly humanist warmth that echoes some of the calligraphic roots in Times New Roman. This makes the two feel related even though one is sans and the other is serif. It works especially for data-heavy pages dashboards, reports, academic sites where Times New Roman handles headings or quotes and Source Sans Pro handles tables, labels, and body text.

Lora + Times New Roman

Lora is a well-balanced serif with moderate contrast and brushed curves. It's a strong substitute when you want the feeling of Times New Roman but need better on-screen rendering. Some designers use Times New Roman only for pull quotes or section headers and let Lora handle the main reading text. The two serifs share enough DNA to feel unified, but Lora's optimized hinting keeps it sharp at body sizes.

PT Sans + Times New Roman

PT Sans was built for legibility across a range of sizes and devices. Its open counters and generous spacing make it a safe choice for mobile-first layouts. Use it at 16px for body copy and pair it with Times New Roman in headings. The contrast is strong enough for clear hierarchy, but the professional tone stays consistent.

Playfair Display + Times New Roman

Playfair Display is a high-contrast display serif inspired by the late Enlightenment era. It draws a sharper, more dramatic contrast when placed next to Times New Roman's even strokes. Use Playfair Display for large hero headings (32px+) and Times New Roman for body or subheadings. This combination suits magazine-style layouts, luxury branding, and editorial portfolios.

How do you set these pairings up for responsive layouts?

The CSS setup matters as much as the font choice. Here's a practical approach:

Load Google Fonts with display=swap. This prevents invisible text while the font downloads. Add the parameter &display=swap to the Google Fonts URL.
Use relative units. Set base font size in rem or em so text scales with the viewport. For example: body { font-size: 1.125rem; } which equals 18px at default browser settings.
Set a fluid type scale. Use clamp() for headings so they shrink and grow smoothly: h1 { font-size: clamp(1.75rem, 4vw, 2.5rem); }
Define your font stack with fallbacks. Always include a system fallback: font-family: 'Open Sans', Arial, Helvetica, sans-serif; for the Google Font and font-family: 'Times New Roman', Times, Georgia, serif; for the system font.
Test at 320px, 768px, and 1200px. These three widths catch most layout problems. If either font looks cramped or oversized at any of these, adjust your clamp values or weight.

Getting the heading and body text pairing right for accessibility also means checking contrast ratios and minimum font sizes not just aesthetics.

What mistakes should you avoid?

Using two similar serifs at body size. Times New Roman next to Georgia at 16px looks like a rendering bug, not a design choice. Make sure the contrast is obvious.
Loading too many font weights. Each weight is a separate file. Pulling in 300, 400, 500, 600, and 700 for two fonts means ten requests. Stick to 400 and 700 for body fonts, and one display weight for headings.
Ignoring line height and letter spacing. Times New Roman needs slightly more line-height (1.6–1.75) than many sans-serifs (1.4–1.6). If you use the same value for both, one will feel too tight.
Forgetting the @font-face fallback order. If you list Times New Roman in quotes but forget the unquoted fallbacks (Times, Georgia), some Linux systems will fall back to a generic serif that looks very different.
Setting body text below 16px. On mobile especially, anything below 16px causes squinting and bouncing zoom behavior on iOS. Keep body text at 16px minimum regardless of which font you use.

Quick tips for better results

Pair a heavier weight of the Google Font (like Roboto 500) with Times New Roman's natural weight to avoid the sans-serif looking washed out next to the bolder serif.
Use Times New Roman sparingly on mobile maybe only for pull quotes or article titles and let the Google Font handle the bulk of the text where screen rendering matters most.
Check your pairing in both light and dark mode if you support it. Some Google Fonts lose contrast on dark backgrounds at lower weights.
Preload the Google Font if it's used above the fold: <link rel="preload" as="font" crossorigin href="font-url.woff2">
Run a Lighthouse audit focused on font performance after adding any new pairing. Watch for layout shift caused by late font swaps.

Checklist before you ship

✅ Pick one Google Font and one role (heading or body) don't swap roles mid-page.
✅ Limit font weights to two per family (400 + 700 is usually enough).
✅ Set body text at 16–18px with a line-height of 1.6+.
✅ Use clamp() for heading sizes so they scale fluidly.
✅ Test the pairing at 320px, 768px, and 1200px viewport widths.
✅ Verify the Google Font loads with display=swap to avoid invisible text.
✅ Check both fonts in dark mode if applicable.
✅ Run a Lighthouse audit to catch performance or CLS issues from font loading.

Start by picking one pairing from this list Open Sans with Times New Roman is the safest starting point for most projects. Set it up with the CSS approach above, test it at three breakpoints, and adjust weights and spacing until both fonts feel balanced. You can always explore more advanced combinations once the basics are solid.