Cascading Style Sheet (CSS)
A Cascading Style Sheet (CSS) is the web-standard language for describing how HTML elements look on screen.
Definition
A Cascading Style Sheet (CSS) is the web-standard language for describing how HTML elements look on screen. It sets colors, fonts, spacing, sizing, and layout through declarative rules that a browser applies to markup. CSS works the same way in Salesforce as anywhere on the web, but the platform wraps it in conventions, security models, and a design system that change how you write and ship it.
In Salesforce, CSS renders Lightning Experience, Lightning Web Components, Aura components, Visualforce pages, Experience Cloud sites, and email templates. Most styling does not start from a blank stylesheet. The Salesforce Lightning Design System (SLDS) supplies base styles, utility classes, and CSS custom properties that components inherit, so the common task is composing what SLDS already gives you. Where you do write CSS, the surface decides the rules: shadow DOM scopes it in components, an iframe isolates it in Visualforce, and email clients strip much of it away.
How CSS behaves across each Salesforce surface
SLDS is the starting point, not raw CSS
The Salesforce Lightning Design System is a CSS framework that delivers the look and feel of Lightning Experience through styles, themes, and utility classes. Salesforce describes the preferred path as composing base components and adding SLDS utility classes, rather than writing bespoke CSS from scratch. Utility classes follow BEM naming (Block Element Modifier), so a left margin reads as class="slds-m-left_medium" on a lightning-button. The official guidance is direct: create your own custom CSS classes instead of targeting SLDS classes, because base component internals can change between releases. Overriding internal markup is explicitly unsupported. SLDS 2, introduced in Spring 25, leans further into CSS custom properties and replaces older design tokens with a system of global styling hooks. That shift matters for anyone maintaining custom styles, because hooks are the supported customization path while direct overrides are the fragile one. Treating SLDS as the foundation keeps your UI visually consistent with the rest of the org and stable across the three releases Salesforce ships each year. Bespoke CSS is still allowed, but it is the exception you reach for after utility classes and styling hooks fall short.
CSS scoping in Lightning Web Components
Every Lightning Web Component can have a CSS file named the same as the component, and the framework applies it automatically. Shadow DOM scopes those styles to the component, so they do not leak out and outside styles do not leak in. That isolation lets you reuse a component anywhere without its appearance breaking. The cascade, specificity, and inheritance rules still apply inside the shadow tree. Inherited properties like color and font cross the shadow boundary, and CSS custom properties traverse it too, which is how theming reaches deep into components. Some features are explicitly not supported. LWC does not allow the :host-context() pseudo-class, the ::part pseudo-element, or ID selectors, because template IDs become globally unique values at runtime and stop matching. The :host selector is supported for styling the component's own element. Scoped CSS carries a performance cost. Each selector chain is scoped and each element gets an extra attribute, which adds bytes, parsing work, and style recalculation time. For light DOM components you can scope styles with a *.scoped.css file instead, applying them only to that component without shadow DOM.
Styling hooks beat CSS overrides
A styling hook is a placeholder in the SLDS stylesheet that works as a CSS custom property. You customize a component by declaring the matching property in your own stylesheet, rather than reaching into SLDS classes. Salesforce is blunt about why: CSS overrides are not supported because SLDS classes and base component internals can change in future releases. Hooks come in two main shapes. Component-level hooks use the --slds-c- prefix, like --slds-c-button-brand-color-background to recolor a button background. Global hooks use the --slds-g- prefix for values used across the whole app. Because hooks are custom properties, they inherit through shadow DOM, so a value you set high in the tree reaches the base components below. When you adopt SLDS 2 global styling hooks, the documented pattern is to provide fallbacks: first an SLDS 1 property, then a static value for environments without SLDS. This keeps a component readable if it renders outside the design system. Styling hooks are the difference between customization that survives an upgrade and CSS that quietly stops working after the next Salesforce release rewrites the internals you targeted.
Aura components and Visualforce
Aura components also carry CSS files, but their scoping is looser than the shadow DOM isolation in Lightning Web Components. Styles leak more readily between Aura components, so a selector meant for one place can quietly affect another. Aura is still supported, and it can consume the same SLDS classes and design tokens, but Salesforce points new development toward LWC, and CSS handling is one reason among several. Visualforce sits in a different world. A Visualforce page can use inline style attributes, an internal style element, or external stylesheets, and it has fewer scoping rules than components. The catch is the frame. When a Visualforce page runs inside Lightning Experience, it renders in an iframe. Styles inside the page do not reach the surrounding Lightning UI, and Lightning styles do not reach into the page. That boundary is useful when you want isolation and frustrating when you want a Visualforce page to visually match the Lightning shell around it. To approximate the Lightning look, Salesforce recommends including the SLDS stylesheet in the page so its markup picks up the same base styling the rest of the org uses.
Experience Cloud branding and Site CSS
Experience Cloud sites style mostly through the builder, not hand-written CSS. In LWR (Lightning Web Runtime) sites, the Theme panel exposes declarative properties for colors, fonts, and spacing, and each property maps to one or more --dxp styling hooks. When someone changes a value in the Theme panel, the system updates every Lightning Web Component that uses the associated hooks, both base and custom. A single hook can therefore retheme the whole site at once. You can also use --dxp hooks directly in custom components so they pick up site branding automatically. Custom CSS still has a place. When styling hooks cannot express exactly what you want, you target preapproved parts of a component with CSS selectors, which keeps customization within supported boundaries rather than overriding internals. Older Aura-based Experience Cloud sites lean on Branding Sets plus an optional Site CSS field, a global stylesheet that applies to every page. The practical rule across both runtimes is the same. Start with theme properties and styling hooks, and treat raw global CSS as the last resort, because broad overrides are the part most likely to break on upgrade.
Email templates and the limits of CSS
Email is where CSS is least reliable, and Salesforce templates inherit that reality. Email clients vary wildly in what they render. Outlook on Windows uses a rendering engine that ignores many modern stylesheet features, and Gmail historically stripped or rewrote internal style elements. The defensive technique is inlining: moving rules into style attributes on each element rather than relying on an internal style block or an external stylesheet. Inlined styles survive far more clients than rules sitting in a head section. Layout often falls back to tables for the same reason, because float and flexbox cannot be trusted across the full set of clients. Marketing Cloud Engagement and the Email Studio editor handle a lot of this inlining for you, so the content you author renders more predictably. Hand-authored email templates in core Salesforce get less help, so you either inline manually or run the HTML through a tool that does it before sending. The takeaway is to assume the smallest common feature set, test the actual template in the clients your audience uses, and never expect an email to honor the same CSS your Lightning UI does.
A worked example: theming a button two ways
Say you want a brand-blue primary button. The wrong instinct is to write .my-button {background: #0b5cab} and force it onto the SLDS button class. That selector reaches into internal markup, so it can break the moment Salesforce restructures the component, and it risks an accessibility regression if the text contrast no longer passes. The supported path uses a styling hook. In your component stylesheet you set --slds-c-button-brand-color-background: #0b5cab, and because the hook is a CSS custom property, the base lightning-button reads it and recolors itself without you touching its internals. The same value can live as a global hook if you want every brand button to match. On an Experience Cloud LWR site you would not write either; you set the color in the Theme panel, which drives the matching --dxp hook across base and custom components at once. The pattern repeats everywhere. Declare intent through hooks and utility classes, let the design system apply it, and keep raw CSS for genuine gaps. This is the habit that separates styling that survives three releases a year from CSS that needs constant repair.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Cascading Style Sheet (CSS).
Hands-on resources to go deeper on Cascading Style Sheet (CSS).
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 does CSS do inside the Salesforce Platform?
Q2. What does the Salesforce Lightning Design System (SLDS) provide for developers writing CSS?
Q3. What does Shadow DOM scoping do for CSS in a Lightning Web Component?
Discussion
Loading discussion…