Failed to find font override values: next/font/google fix

TL;DR#

next/font/google builds a size-adjusted fallback face from a table of font metrics that ships inside Next.js. When the Google font you import is not in that table, Next.js prints Failed to find font override values for font and skips the fallback. The build still succeeds. To silence the warning on both bundlers, set fallback (which stops the Turbopack lookup) and adjustFontFallback: false (which stops the webpack lookup). To get the layout-shift protection back as well, self-host the same file with next/font/local, which measures the font itself.

On Next.js 16.4.3, plain next build (Turbopack) prints:

Turbopack build encountered 1 warning:
./
Warning: Failed to find font override values for font `Cal Sans`
Skipping generating a fallback font.

and next build --webpack prints:

⨯ Failed to find font override values for font `Cal Sans`

The original report, vercel/next.js#47115 (internally NEXT-1192), showed the Next.js 13 dev-server form for the Unbounded font:

error - Failed to find font override values for font `Unbounded`

Why next/font/google cannot find the override values#

By default, next/font/google adds a second @font-face called <Font> Fallback that points at a local system font (Arial or Times New Roman) with ascent-override, descent-override, line-gap-override and size-adjust values, so that text set in the fallback takes up roughly the same space as the web font. The next/font API reference describes adjustFontFallback for Google fonts as "A boolean value that sets whether an automatic fallback font should be used to reduce Cumulative Layout Shift" and gives its default as true.

Those override values are not computed from the font file. They come from a precalculated JSON file, dist/server/capsize-font-metrics.json, generated from the @capsizecss/metrics package. The webpack loader looks it up through calculateSizeAdjustValues in font-utils.ts, called from get-fallback-font-override-metrics.ts, whose own comment admits the limitation: "That way we don't have to update the precalculated values every time a new font is added to Google Fonts." If the family is missing, the lookup throws and the catch block logs the error you see.

The list of Google families that next/font/google accepts and the metrics table are two separate snapshots, and they drift apart. Comparing them in the published next@16.4.3 package (using the same key function as font-utils.ts) gives 1,942 importable families and 220 with no metrics entry, among them Cal Sans, Google Sans, Google Sans Code, TikTok Sans, Cascadia Code, Atkinson Hyperlegible Next and Libertinus Serif. Next.js 16.4.3 pins @capsizecss/metrics 3.4.0; version 4.4.0 of that package does include Cal Sans, but next@16.5.0-canary.26 still has no Cal Sans entry.

That drift is also why issue #47115 kept collecting "same issue with …" comments for almost a year. It was closed after PR #62309 ("update capsize css so fallbacks are updated") refreshed the metrics; that commit first appears in the v14.1.1-canary.66 tag and is part of v14.2.0. The fonts people were reporting then (Unbounded, Geologica, Onest, Instrument Sans, Bricolage Grotesque) all have entries in 16.4.3. Newer families do not.

Turbopack and webpack check different options#

This is the part the issue thread predates. The two bundlers decide whether to look the font up in different ways:

• webpack (loader.ts) only calls the metrics lookup when adjustFontFallback is true.
• Turbopack (font_fallback.rs) skips the lookup only when you pass a fallback array. Otherwise it searches the table first and fails with "Font not found in metrics" before it ever reads adjustFontFallback, then emits a warning with the description "Skipping generating a fallback font."

So adjustFontFallback: false, the answer a maintainer (samcx) confirmed in the issue, still leaves the Turbopack warning in place, and the next CLI reference lists Turbopack as enabled by default for next build, with --webpack to build using the bundled webpack instead. The build banner tells you which one ran: ▲ Next.js 16.4.3 (Turbopack) or ▲ Next.js 16.4.3 (webpack).

Fix the warning, then decide about the fallback#

Every step below was reproduced on 24 October 2026 with Next.js 16.4.3, React 19.2.0 and Node 22 in the official node:22-bookworm-slim Docker image, using the App Router and a root layout that imports Cal_Sans.

1. Confirm the font is the cause#

Look for the family name in the warning, then check that a font Next.js does have metrics for builds without it. With Inter and no options, Turbopack generated the fallback face and printed no warning:

@font-face{font-family:Inter Fallback;src:local(Arial);ascent-override:90.44%;descent-override:22.52%;line-gap-override:0.0%;size-adjust:107.12%
.rRjk0G_className{font-family:Inter,Inter Fallback;font-style:normal

With Cal_Sans, there is no Cal Sans Fallback face and the class has no fallback family at all:

.__className_be3b3f{font-family:Cal Sans;font-weight:400;font-style:normal

2. Silence it on both bundlers#

Give the font an explicit fallback stack and turn off the automatic adjustment. This is app/layout.js:

import { Cal_Sans } from 'next/font/google'
 
const calSans = Cal_Sans({
  weight: '400',
  subsets: ['latin'],
  fallback: ['system-ui', 'arial'],
  adjustFontFallback: false,
})
 
export default function RootLayout({ children }) {
  return (
    <html lang="en-GB">
      <body className={calSans.className}>{children}</body>
    </html>
  )
}

Each option alone fixes only one bundler. In the reproduction, adjustFontFallback: false by itself left the Turbopack warning, and fallback by itself left the webpack one. With both, Turbopack and webpack builds were clean, and the generated class now names a real fallback stack:

.__className_be3b3f{font-family:Cal Sans,system-ui,arial;font-weight:400;font-style:normal

Silencing costs nothing in layout shift compared with the warned state: in both cases no metric-adjusted fallback exists. It only removes noise, and fallback makes the browser use system-ui instead of the browser's default font while the font loads.

3. Or self-host the font to get the adjusted fallback back#

next/font/local reads the font file and computes the override values itself, so it does not depend on the metrics table. Download the woff2 file (check the font's licence before redistributing it), put it in app/fonts/, and load it locally:

import localFont from 'next/font/local'
 
const calSans = localFont({
  src: './fonts/CalSans-Regular.woff2',
  weight: '400',
})
 
export default function RootLayout({ children }) {
  return (
    <html lang="en-GB">
      <body className={calSans.className}>{children}</body>
    </html>
  )
}

With the latin subset of Cal Sans, both bundlers generated a size-adjusted fallback face (Turbopack output shown):

@font-face{font-family:calSans Fallback;src:local(Arial);ascent-override:98.6%;descent-override:29.58%;line-gap-override:0.0%;size-adjust:101.42%
._3oV3cq_className{font-family:calSans,calSans Fallback;font-weight:400

Note the family name: next/font/local names the face after the variable (calSans), not after the font. If Tailwind or your own CSS refers to the font by name, use the variable option and point the CSS at the custom property instead. A hand-written @font-face whose family name does not match the one your utility class outputs fails silently, as the Tailwind custom font page shows.

Verify the fix#

Delete the build output so nothing stale is reused, then build with the bundler you deploy with:

rm -rf .next
npx next build
npx next build --webpack

The warning lines must be gone from both runs. Then check the generated CSS: grep .next/static for font-family: and confirm the class lists your fallback stack (step 2) or a Fallback face with size-adjust (step 3). If the warning comes back after an upgrade, check the exact release first: in the issue, a commenter saw it again on 14.1.2, a backport release that did not include the metrics refresh, while 14.2.0-canary.0 was clean.

Fixes from the issue thread that do not change anything#

Several answers in #47115 do not touch the code path:

• display: 'swap'. The API reference lists 'swap' as the default for display, and the issue's own reproduction already set it and still got the warning. The webpack loader decides on adjustFontFallback, Turbopack on fallback; neither reads display.
• Restarting the dev server. The metrics table is static data inside the next package; a restart reads the same file.
• A hand-written @font-face in global CSS. It works because it stops using next/font/google for that family, which is the self-hosting route of step 3 without the automatic fallback.

If your Next.js build fails rather than warns, this message is not the cause: the warning never stops next build. Read the first error above the failure instead, as described in the Export encountered errors guide. For where fonts sit among the other Core Web Vitals levers, see the font section of the Next.js performance guide.

The warning is a data gap rather than a bug in your code: Next.js knows the font exists on Google Fonts but has no measurements for it yet. Silence it with fallback plus adjustFontFallback: false if a plain fallback stack is good enough, switch to next/font/local if layout shift matters on that page, and recheck after a Next.js upgrade whether the family has been added to capsize-font-metrics.json.