Add Tailwind CSS to a converted Framer site

You can add Tailwind CSS to a converted Framer site and keep the CSS modules it came with. With Tailwind v4, install it, import only its theme and utilities (skip Preflight, its reset, so the converted pages don't shift), and map the site's colour tokens into @theme so classes like bg-brand use the designer's colours. Use Tailwind for new work and small edits; leave the generated CSS modules alone until you have a reason to rewrite a component.

This guide uses the default Next.js target from Deframer and notes the differences for the other frameworks. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer, and it converts only sites you own or have permission to convert.

Should you add Tailwind at all?

The converted project already has a styling system: each component and view has a CSS module, colour styles are CSS variables in src/styles/tokens.ts, and text styles are global classes in src/styles/text/. That's enough to maintain the site. Tailwind earns its place when:

• Your team already writes Tailwind everywhere else and wants one way to style new sections.
• You're building new pages or app screens next to the marketing site, as in adding a backend.
• You use AI tools that produce Tailwind markup by default.

It's a poor reason to add Tailwind if the plan is to "clean up" the generated CSS by rewriting it all. That's a large change with a high risk of visual regressions, for no visible gain.

How do the two systems fit together?

Both end up as ordinary CSS, so they coexist. The rules below are about keeping them from fighting.

Step 1: Install Tailwind v4

Tailwind v4 is configured in CSS, not in a tailwind.config.js. For Next.js, install the PostCSS plugin:

npm install tailwindcss @tailwindcss/postcss postcss

Create postcss.config.mjs at the project root:

export default {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

Commit this on a branch of its own, before you write any classes, so the setup is easy to review.

Step 2: Import theme and utilities, not Preflight

The usual one-liner, @import "tailwindcss";, includes Preflight, a CSS reset that changes defaults for margins, headings, lists, images and borders. The converted pages were styled against the published site's own base styles, so Preflight can move things: images become block elements, heading sizes reset, list bullets disappear.

Import the layers individually instead, leaving Preflight out. The converted project's global stylesheet is src/app/globals.css, imported by the root layout. Add to the top of it:

@layer theme, base, components, utilities;
@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/utilities.css" layer(utilities);

Run npm run dev and look at a few pages at desktop and phone widths. Nothing should have moved. If something did, check that Preflight really is out.

Step 3: Map the Framer tokens into @theme

Colour styles in a converted project are CSS variables named after the designer's styles, such as --token-dark-8 or --token-brand. Where a style had no published name, the variable is named after its value. Open src/styles/tokens.ts to see your site's names.

Map the ones you'll use into Tailwind's theme with @theme inline, which makes each utility reference the variable directly:

@theme inline {
  --color-brand: var(--token-brand);
  --color-ink: var(--token-dark);
  --color-ink-muted: var(--token-dark-8);
  --color-surface: var(--token-white);
}

Now bg-brand, text-ink and border-ink-muted use the same values as the converted components. Change a token in tokens.ts and both the CSS modules and the Tailwind classes follow. Because inline keeps the var() reference at the point of use, a site whose tokens switch for dark mode keeps switching.

Do the same for fonts if you want font utilities to match. The @font-face rules are in src/styles/fonts/; reference the family names they declare:

@theme inline {
  --font-display: "Inter Display", sans-serif;
}

Use the family name your site actually declares.

Step 4: Match the breakpoints

Framer sites usually have Desktop, Tablet and Phone breakpoints, and the converted project writes them as media queries. Tailwind's default breakpoints are different numbers. If you want md: and lg: to switch exactly where the converted layouts switch, set them in @theme:

@theme {
  --breakpoint-md: 810px;
  --breakpoint-lg: 1200px;
}

The values above are only an example: copy yours from the media queries in a view's CSS module or the text styles in src/styles/text/. How Framer breakpoints become responsive layouts explains how the breakpoints are written.

Step 5: Know who wins: cascade layers

This is the detail that surprises people. With the setup above, Tailwind's utilities live in the utilities cascade layer. The converted CSS modules are not in any layer. In CSS, unlayered styles beat layered ones regardless of specificity.

So on an element that already has a module class setting padding, adding p-8 does nothing. That's usually what you want: Tailwind can't silently change a converted component. When you do want a utility to win on such an element, you have two honest options:

1. Edit the CSS module. The property lives there; change it there.
2. Use the important modifier for a one-off, in v4 written with a trailing !: p-8!.

On new elements you write yourself, with no module class, utilities apply normally.

Step 6: Where to use Tailwind

A pattern that stays maintainable:

• New sections and pages: Tailwind, using the theme colours from step 3.
• Small edits to converted components: edit the CSS module. It's the component's source of truth.
• Rewriting a converted component: allowed, but as its own task, compared visually before and after. Visual regression tests make this safe.

Write the rule into your project notes so AI tools follow it too; the AGENTS.md guide has a sample.

Other frameworks

The CSS part, steps 2 to 5, is the same everywhere. The install differs:

Check Tailwind's own installation guide for your framework; it changes more often than the project layout does.