KATLA FOR NEXT.JS

Cookie consent that respects the App Router.

A typed SDK with a provider, hooks and Consent Mode v2 built in. Everything you pass through the provider stays a Server Component, the banner is yours or ours, and nothing blocks render.

@katla.app/sdkApp Router + Pages RouterConsent Mode v2 built in
app/layout.tsxApp Router
import { KatlaNextProvider } from '@katla.app/sdk/next'

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <KatlaNextProvider siteId="your-site-id" googleConsentMode>
          {children}
        </KatlaNextProvider>
      </body>
    </html>
  )
}
The provider is the only client boundary — children stay on the serverFull guide
WHY NEXT.JS SITES STRUGGLE WITH CONSENT

Most consent platforms were built for a script tag and a page reload.

THE PROBLEMThe banner is a third-party iframe or a global script that hydration ends up fighting with.
WITH KATLAA React provider and typed hooks instead. Consent state lives in your tree and re-renders the components that read it, like any other state.
THE PROBLEMAnalytics and pixels are loaded with next/script before the visitor has decided anything.
WITH KATLAGate them on useKatlaConsent() and render the tag only once its category is granted. The Consent Mode v2 signals come from the same state, so the two cannot disagree.
THE PROBLEMA hosted banner ignores your design tokens, and restyling it is a fight with a stylesheet.
WITH KATLAHeadless mode ships no interface at all. Build the banner from your own components, or take CookieBanner — it is unstyled, with stable katla-* class names and a render prop.
SETUP

Four steps, one dependency.

  1. Installpnpm add @katla.app/sdk. About 5 KB over the wire in headless mode.
  2. Wrap the layoutAdd KatlaNextProvider to app/layout.tsx with your site ID. It injects the cookie guard itself.
  3. Gate your scriptsPut analytics and marketing tags behind a useKatlaConsent() check.
  4. Ship a bannerDrop in CookieBanner, or build your own from useConsentManager().
BUILT FOR NEXT.JS

The parts a Next.js team actually needs.

Server-side prefetchgetCachedCookies() reads the inventory in a Server Component, deduplicated with React cache(). Pass it as initialCookies and the browser makes no request.
Consent Mode v2One googleConsentMode prop drives ad_storage, analytics_storage, ad_user_data and ad_personalization. Denied by default, updated on the decision.
Streaming-safeNo render-blocking script and no layout shift. The provider carries the "use client" boundary so your pages do not have to.
Typed end to endCategories, consent state, cookie data and policy locales are all typed. Autocomplete instead of a docs tab.
Builds with no runtime fetchkatla pull writes the inventory and the guard into .katla/; getStaticGuardScript() inlines the guard into the document. Nothing is fetched at page load.
Policies as componentsKatlaPolicy renders the generated cookie or privacy policy, server-fetched with getCachedPolicy(), in any of 13 languages.
CORE WEB VITALS

That's how the cookie crumbles. Except your SEO shouldn't.

A consent script is the first third party on every page, which is why it shows up in the Core Web Vitals report. In headless mode Katla is 5 KB over the wire — and inlined from .katla/ it is not a request at all — so LCP and INP stay where your build put them.

How headless mode works
5 kBOver the wireGuard and consent API, brotli
0 msAdded LCPAgainst the same page without it
0Layout shiftThe banner reserves no space in flow
1RequestOne script, cached at the edge

Our own measurements, taken how they were taken.

Questions Next.js teams ask

Does it work with the Pages Router?
Yes. Import from @katla.app/sdk/react and wrap _app.tsx instead of app/layout.tsx. The hooks and components are the same ones.
Can I read cookie data on the server?
Yes — getCachedCookies() and getCachedPolicy() from @katla.app/sdk/next/server run in Server Components and are deduplicated per render. The consent decision itself is made in the browser, so it is read through useKatlaConsent() rather than on the server.
How does this compare to next/third-parties?
They are complementary. next/third-parties loads the tags; Katla decides whether they are allowed to load, blocks the cookies until they are, and keeps the record of the decision.
What about i18n routes?
Pass locale to the provider and the generated policies and cookie descriptions come back in that language. Thirteen are supported, from en-GB to sv-SE.
KATLA FOR

Add consent to your Next.js app before lunch.

The free plan scans your Next.js site and generates a cookie policy, without a card.

Get started free