Hello I'm trying to add a local font that I've downloaded to my next.js project but I'm having trouble loading it in my project.
// src/app/layout.tsx
import localFont from 'next/font/local'
const dinround = localFont({
src: [
{
path: '../../public/fonts/DIN Round Pro/dinroundpro.otf'
}
],
variable: '--font-dinround'
})
export default function RootLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
return (
<html lang="en">
<body className={`${geistSans.variable} ${geistMono.variable} ${dinround.variable} antialiased`}>
{children}
</body>
</html>
);
}
In the next js docs it says to add the variables to the tailwind.config.js file but for tailwind 4 there isn't a config file anymore. there's a postcss.config.mjs file but I don't think that's the same thing, So I assumed I do it in my globals.css file.
// src/styles/globals.css
@import "tailwindcss";
@plugin "daisyui" {
themes: light --default, dark;
root: ":root";
logs: true;
}
@theme {
}
So I'm unsure of how to add the variables that I added to the layout.tsx file in my tailwind config file to use throughout my app.
@theme
directiveYour description was written for TailwindCSS v3. You're right, starting from v4, there's no need for tailwind.config.js
.
vercel/next.js
#75384: Docs: Outdated tailwind docs for the tailwind v4 release - GitHubInstead, they introduced a CSS-first configuration approach with many useful and simple directives. Here's how you can add a font:
@theme
directive - TailwindCSS v4 Docs./src/styles/globals.css
@theme {
--font-display: "Satoshi", "sans-serif";
}
You can customize our theme using the @theme
directive, which previously had to be done under the extends.theme
key in tailwind.config.js
. I've attached the table to different namespaces - for fonts, you can use --font-*
.
Specifically, adding your font:
./src/styles/globals.css
@theme {
--font-dinround: var(--font-dinround);
}
In addition, Tailwind v4 still includes the legacy JavaScript-based configuration, although I recommend trying out the new CSS-first approach; it's likely they won't maintain two separate configuration types in the future. For the legacy JavaScript-based configuration, follow this: