A Next.js root layout calls `Inter({ subsets: ['latin'], variable: '--font-inter' })` from `next/font/google` and assigns the result to `inter`. What is on that returned object, and which property do you use to make the font available to arbitrary CSS rules rather than to one element?

## The shape of what the loader returns A font loader call in Next.js is replaced at build time by an object literal. It has three properties worth knowing: - **`className`** — a generated, hashed class name. The generated CSS for that class sets `font-family` to the font plus its fallback stack. If you requested exactly one weight and style, it sets those too. - **`style`** — the same information as a React inline-style object, e.g. `{ fontFamily: '...' }`. Useful when you cannot add a class, such as styling an element whose class list is controlled by a third party. - **`variable`** — present **only** when you passed a `variable` option. It is another generated class name, and the crucial thing is what its CSS rule contains: the custom property assignment, and *not* a `font-family` declaration. That last distinction is the whole question. Candidates routinely assume `inter.variable` is the string `'--font-inter'` you passed in. It is not; it is a class name you attach to an element so the custom property exists on that element and everything beneath it. ## Direct application: className The simplest wiring puts the class on the body in the root layout: ```tsx import { Inter } from 'next/font/google' const inter = Inter({ subsets: ['latin'] }) export default function RootLayout({ children }) { return ( <html lang="en"> <body className={inter.className}>{children}</body> </html> ) } ``` Everything inherits the family. This is right when there is one font, but it hard-codes the decision into JSX: if a heading should use a different family, you have to reach for that font's `className` on the heading too, and now your typography decisions live scattered across components instead of in CSS. ## Indirect application: variable With the `variable` option, the wiring inverts: ```tsx const inter = Inter({ subsets: ['latin'], variable: '--font-inter' }) const mono = Roboto_Mono({ subsets: ['latin'], variable: '--font-mono' }) // <html className={`${inter.variable} ${mono.variable}`}> ``` Both classes go on the same element. Because neither sets `font-family`, nothing visibly changes yet — you have only made two custom properties available on the root. CSS then owns the mapping: ```css body { font-family: var(--font-inter), system-ui, sans-serif; } pre, code { font-family: var(--font-mono), monospace; } ``` This is also the shape a utility-CSS framework wants: you register `var(--font-inter)` as the theme's sans family once, and every `font-sans` utility resolves to it. The React tree stops knowing anything about typography beyond "the variables are declared at the root". Note the family names you get from a generator are hashed and not stable to type by hand, which is exactly why the custom property exists — it is the stable name you are allowed to reference. ## Choosing between them Use `className` when a single element or subtree should be in a given face and nothing else needs to know: a marketing hero, a code block in one component. Use `variable` when more than one family is in play, when a CSS framework's theme should be the source of truth, or when you want to switch families with a CSS class or media query rather than by re-rendering different components. The two are not exclusive — a common pattern is `variable` on `<html>` for the design-system wiring plus `className` on `<body>` for the default body font, which is legitimate as long as you understand you are applying two different rules. ## Where the call must live One structural point that catches people: the object is produced at build time, so the loader call belongs at module scope, and sharing the same font across files means exporting that constant from a small module (often `app/fonts.ts`) and importing it. Calling the loader again in a second file with the same options is not an error, but it is a second declaration to reason about; exporting one constant keeps a single source of truth for the family and its custom-property name. ## Subsets and the option object `subsets` is not decoration. It selects which character ranges are fetched and embedded, which directly controls file size — asking for `['latin']` on a family that also ships Cyrillic and Greek avoids shipping glyphs nobody renders. For Google fonts the loader wants this decided explicitly, because it also determines which files are worth preloading. If you request a non-variable family you must also pass `weight`; for a variable font the weight range comes from the file itself and the option is unnecessary.