Astro CSS options all compile to plain CSS with no runtime, so the choice is about how your team works, not performance. Scoped <style> blocks plus a small global stylesheet suit most sites and need no tooling. Tailwind CSS suits teams who already use it or build many sites from shared components. CSS Modules and Sass make sense mainly when you’re bringing an existing codebase. Whichever you choose, keep design values in CSS custom properties so a rebrand is one file.
Key Takeaways
- Scoped styles + global tokens: zero setup, easiest for people who know CSS.
- Tailwind: fastest for teams fluent in it, consistent across many projects.
- Sass or CSS Modules: bring them if you already have them; new projects rarely need them.
- CSS-in-JS only works inside framework islands; avoid it for site-wide styling.
Decision flow
- Does your team already use Tailwind daily? Yes → Tailwind.
- Are you migrating a project with lots of Sass or CSS Modules? Yes → keep them; Astro supports both with no config beyond installing
sass. - Will non-specialists edit styles later (clients, designers who write CSS)? Yes → scoped styles + tokens.
- Are you building many sites from one component library? Tailwind or tokens + scoped styles both work; pick the one your team reads faster.
- Otherwise → scoped styles + a global token file.
Compared
| Approach | Setup | Learning curve | Strengths | Watch out for |
|---|---|---|---|---|
Scoped <style> + global tokens |
None | CSS only | Readable, no build deps, styles live with markup | Discipline needed to keep tokens central |
| Tailwind CSS | npx astro add tailwind |
Utility vocabulary | Fast iteration, consistent spacing, tiny CSS output | Long class lists, harder for CSS-only editors |
| CSS Modules | None (*.module.css) |
Low | Explicit class mapping | Redundant with scoped styles in .astro files |
| Sass | npm i -D sass |
Low | Mixins, loops, existing code | Native CSS covers most features now |
| CSS-in-JS | In islands only | Varies | Familiar to React teams | Runtime cost, doesn’t style .astro components |
The part that matters regardless: tokens
/* src/styles/tokens.css */
:root {
--color-brand: #2563eb;
--color-text: #14140f;
--radius: 0.75rem;
--space-section: clamp(4rem, 8vw, 8rem);
}Scoped styles reference var(--color-brand); Tailwind maps the same values in @theme. Either way, a client’s new brand colour is one edit. The Astro styling guide has a worked rebrand example.
By project type
| Project | Recommendation |
|---|---|
| Personal blog or portfolio | Scoped styles + tokens |
| Agency building client sites | Tailwind or scoped + tokens, whichever the team standardises on |
| Docs site on Starlight | Starlight’s CSS custom properties; light overrides |
| Large marketing site with a design system | Tokens shared with the design system; Tailwind if the system already uses it |
| Migration from a Sass codebase | Keep Sass, move tokens to custom properties over time |
Mixing approaches
You can combine them. A common, sensible mix: Tailwind for layout and spacing, a global stylesheet for typography and tokens, and occasional scoped <style> blocks for complex one-off components. Avoid mixing two utility frameworks or two token systems.
Related: using Sass in Astro and define:vars for per-instance values. The styling docs for Komal themes show how a theme organises its tokens. Tailwind’s Astro setup guide covers installation.
FAQ
Does Tailwind make an Astro site faster?
Not meaningfully. All approaches compile to static CSS. Tailwind output is usually small because only used utilities are generated.
Can I use Tailwind and scoped styles together?
Yes. Utility classes and scoped <style> blocks work side by side in the same component.