Cascading Style Sheet (CSS)
Cascading Style Sheet (CSS) in Salesforce is the same web-standard styling language used everywhere else on the web: a declarative rules language that sets colours, fonts, spacing, layout, and other visual properties for HTML elements.
Definition
Cascading Style Sheet (CSS) in Salesforce is the same web-standard styling language used everywhere else on the web: a declarative rules language that sets colours, fonts, spacing, layout, and other visual properties for HTML elements. Salesforce uses CSS to render Lightning Experience, Lightning Web Components, Aura Components, Visualforce pages, Experience Cloud sites, Email Templates, and Salesforce-built mobile interfaces. Most Salesforce developers write CSS in component-scoped files (one stylesheet per Lightning Web Component), in legacy global stylesheets (for Visualforce), or in Experience Cloud Builder's branding panel.
CSS in Salesforce comes with platform-specific constraints. The Salesforce Lightning Design System (SLDS) ships the design tokens, base styles, and utility classes that Lightning Experience and Lightning Web Components inherit. Developers are encouraged to compose SLDS classes rather than write bespoke CSS from scratch. Locker Service (the now-retired security wrapper) and Lightning Web Security (its replacement) impose limits on CSS in Lightning components, particularly around shadow DOM scoping and access to certain global selectors. Visualforce pages have fewer constraints but render in an iframe in Lightning Experience, which limits cross-frame styling. Experience Cloud sites apply CSS through Branding Sets and global stylesheets, with theme tokens that propagate to every component.
How CSS works across Salesforce surfaces
Salesforce Lightning Design System
SLDS is Salesforce's design system that ships base styles, design tokens (colours, spacing, typography), and a library of utility classes. Developers build Lightning components by composing SLDS classes; bespoke CSS is the exception, not the rule. SLDS guarantees visual consistency across the Lightning Experience surface and updates with each release.
CSS in Lightning Web Components
Each Lightning Web Component has its own CSS file scoped to that component through shadow DOM. Styles do not leak out and external styles do not leak in. The scoping is enforced by Lightning Web Security; reaching across components requires the slot-based styling or explicit CSS custom properties.
CSS in Aura Components
Aura Components have CSS files but with looser scoping than LWC. Styles can leak more readily. The legacy framework is supported but Salesforce recommends LWC for new development; CSS handling is one of several reasons.
CSS in Visualforce
Visualforce pages can include inline style attributes, internal style elements, or external stylesheets. Visualforce inside Lightning Experience renders in an iframe; styles inside the page do not affect the surrounding Lightning UI, and Lightning styles do not affect the Visualforce content. The iframe boundary is the constraint.
Experience Cloud Branding and CSS
Experience Cloud sites style through Branding Sets (theme tokens) plus the optional Site CSS field for custom styles. Site CSS is a global stylesheet applied to every page; Branding Sets propagate theme tokens to standard components. Most Experience Cloud customisation uses Branding Sets first and Site CSS only when tokens are not enough.
Lightning Web Security and the CSS implications
Lightning Web Security (LWS) replaced Locker Service. LWS uses a different security model that allows more standard CSS behaviour while still preventing component-to-component leaks. Migrating from Locker to LWS occasionally surfaces CSS that worked under Locker's looser rules and breaks under LWS's stricter ones.
Email Template CSS
Email clients render CSS inconsistently. Salesforce email templates that include CSS often need inline styles (rather than internal style elements) to render reliably across Outlook, Gmail, Apple Mail, and mobile clients. Marketing Cloud Engagement and the Email Studio editor handle the inlining automatically; raw Email Template authoring requires manual inlining for cross-client compatibility.
Common pitfalls
Three patterns recur. Custom CSS that overrides SLDS produces accessibility regressions and breaks on every Salesforce release. Component-level CSS that assumes global scope breaks under LWS. And Experience Cloud Site CSS that ignores Branding Set tokens makes theming inconsistent across pages. Composing with SLDS and Branding Sets is almost always the right starting point.
How to write CSS for Salesforce
CSS in Salesforce is most useful when it composes with SLDS and respects component scoping. Bespoke CSS is the exception, not the rule.
- Start with SLDS classes
Compose Lightning Web Components from SLDS utility classes (slds-grid, slds-text-heading_medium). Custom CSS only fills the gaps SLDS does not cover.
- Scope CSS to the component
Write CSS in the component's own stylesheet file. Avoid global selectors; LWS scoping enforces component boundaries.
- Use design tokens for theme values
Reference SLDS design tokens (var(--lwc-colorBrand)) rather than hard-coded colours. Tokens propagate theme changes automatically.
- For Experience Cloud, use Branding Sets first
Configure Branding Sets in Experience Builder. Add Site CSS only when Branding Sets cannot cover the design need.
- Test across surfaces
LWC, Aura, Visualforce, Email Templates, Experience Cloud each render CSS differently. Test the styling in every surface it ships to before launch.
- Custom CSS overriding SLDS produces accessibility regressions and breaks on Salesforce releases. Compose with SLDS, do not fight it.
- LWC enforces shadow DOM scoping. Selectors that reach across components fail; communicate through CSS custom properties or slots.
- Email Template CSS needs to be inlined for cross-client compatibility. Internal style elements do not render reliably in Outlook.
- Experience Cloud Site CSS overrides Branding Sets. Mixing both creates inconsistent theming; pick one as the primary source.
Trust & references
Cross-checked against the following references.
- Salesforce Lightning Design SystemSalesforce
- Lightning Web Components Developer GuideSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Cascading Style Sheet (CSS).
- Lightning Web SecuritySalesforce Developer Docs
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is CSS used for in Salesforce?
Q2. What does Salesforce's SLDS provide?
Q3. What is Shadow DOM scoping in LWC?
Discussion
Loading discussion…