How to Fix: next/font Roboto_Flex cannot have axis set

Updated June 8, 2026 5 min read

Aldawsari

5 min read

Roboto Flex fails when you pass an axes option to next/font/google because the generated font request and validation logic do not support that configuration for this variable font in the affected Next.js versions. The result is a build-time or dev-time failure even though Roboto Flex itself supports multiple variation axes.

Understanding the Root Cause | Step-by-Step Solution | Common Edge Cases | FAQ

Understanding the Root Cause

The issue happens at the boundary between Google Fonts variable font metadata and Next.js font loader validation. Roboto Flex is a variable font with many axes such as weight, width, optical size, and slant. However, in the affected implementation of next/font, not every axis configuration exposed by Google Fonts is accepted through the axes field for every font.

In practice, next/font/google expects a known, validated set of options for each font. For Roboto_Flex, the loader can reject custom axis input even though the underlying font supports it. That means the bug is not really that Roboto Flex lacks axes; it is that Next.js cannot correctly translate or permit the requested axis configuration for this font in that version.

This also explains why the problem reproduces immediately in development. The font loader runs during compilation, validates the font options, and throws before your app can render normally.

So the root cause is:

Roboto Flex is a multi-axis variable font.
next/font/google performs option validation and request generation.
In the affected version, the axes option for Roboto_Flex is not handled correctly.
The fix is to avoid unsupported axis configuration or switch to a loading approach that gives you direct control.

Step-by-Step Solution

The most reliable fix is to remove the unsupported axes option from Roboto_Flex and use only the options that Next.js currently handles correctly, such as subsets, weight when applicable, and variable.

1. Find the failing font declaration

You will usually have code similar to this:

import { Roboto_Flex } from 'next/font/google'

const robotoFlex = Roboto_Flex({
  subsets: ['latin'],
  axes: ['opsz', 'slnt'],
  variable: '--font-roboto-flex'
})

The problematic part is the axes property.

2. Remove the axes option

Replace it with a supported configuration:

import { Roboto_Flex } from 'next/font/google'

const robotoFlex = Roboto_Flex({
  subsets: ['latin'],
  variable: '--font-roboto-flex',
  display: 'swap'
})

This keeps the font working through next/font without triggering the loader bug.

3. Apply the font through the generated CSS variable or className

If you are using the App Router, a common pattern looks like this:

import { Roboto_Flex } from 'next/font/google'
import './globals.css'

const robotoFlex = Roboto_Flex({
  subsets: ['latin'],
  variable: '--font-roboto-flex',
  display: 'swap'
})

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={robotoFlex.variable}>
      <body>{children}</body>
    </html>
  )
}

Then in CSS:

:root {
  font-family: var(--font-roboto-flex), sans-serif;
}

4. If you need custom axis control, use CSS font-variation-settings

If the font loads successfully as a variable font, you may still be able to control some behavior in CSS instead of through the Next.js axes option.

.headline {
  font-family: var(--font-roboto-flex), sans-serif;
  font-variation-settings: 'opsz' 144, 'slnt' -10;
}

This is often the best workaround when the loader blocks axis declaration but the browser can still render the loaded variable font.

5. If CSS control is not enough, switch to local font hosting

When you need precise axis-level control and the Google font loader path is limiting you, host the font yourself with next/font/local.

import localFont from 'next/font/local'

const robotoFlex = localFont({
  src: './fonts/RobotoFlex-Variable.woff2',
  variable: '--font-roboto-flex',
  display: 'swap'
})

Then apply axis settings in CSS:

.headline {
  font-family: var(--font-roboto-flex), sans-serif;
  font-variation-settings: 'opsz' 144, 'wdth' 120, 'slnt' -10;
}

This bypasses the specific next/font/google validation problem.

6. Upgrade Next.js and test again

If the issue is fixed in a later release, upgrading may restore support or improve validation behavior. After updating, rerun the app and verify the font setup:

npm install next@latest react@latest react-dom@latest
npm run dev

Before upgrading in production, review the relevant release notes on the Next.js blog.

Common Edge Cases

Using unsupported axis tags: Even if a font is variable, not every axis name may be accepted by the loader. Prefer CSS-based variation control if the loader rejects the configuration.
Assuming axes and weights are interchangeable: The wght axis is often represented through standard font-weight usage, while other axes like opsz or slnt may require font-variation-settings.
Browser rendering differences: Some browsers handle variable font interpolation differently. Test your typography in Chromium, Safari, and Firefox if you rely on advanced axis settings.
Local font file mismatch: If you switch to next/font/local, make sure the downloaded variable font file actually includes the axes you expect. Not all distributed files expose the same axis range.
Hydration confusion: The bug is not usually a hydration issue. If the app crashes before render, the failure is likely in the font loader validation step, not in client-side React.
App Router vs Pages Router differences: The import pattern is similar, but where you attach the generated class or variable can differ. Ensure the font variable is applied at a high enough level, such as the root layout or custom app component.

FAQ

Can I still use Roboto Flex with Next.js?

Yes. The safe path is to use Roboto_Flex without the problematic axes option, then apply variation through CSS if needed.

Why does Roboto Flex support axes in theory but fail in next/font?

Because the limitation is in the Next.js font integration layer, not necessarily in the font itself. The loader validates a narrower set of options than the raw variable font format allows.

What is the best workaround if I need full variable-font control?

Use next/font/local with a local Roboto Flex variable font file and manage axis values through font-variation-settings in CSS. That gives you the most predictable behavior.

If you want the simplest production-safe resolution for this specific issue, remove axes from Roboto_Flex, keep the font loaded through next/font, and move axis customization into CSS or local font hosting.