Salesforce Lightning (SLDS)
🍀 Directory Note
"The enterprise-CRM reference: the deepest blueprint library for dense, record-based work, priced in platform commitment, and currently mid-transition between its token-based first generation and the styling-hooks architecture of SLDS 2."
About Salesforce Lightning (SLDS)
The Salesforce Lightning Design System (SLDS) is the design system for building on the Salesforce platform, and it documents itself as component blueprints: framework-independent HTML and CSS specifications that Salesforce's own base Lightning components implement, and that developers follow to build custom components matching Lightning Experience. It currently exists in two generations at once. SLDS 1, documented at v1.lightningdesignsystem.com, is the classic CSS framework, published on npm as @salesforce-ux/design-system (version 2.264.3, checked October 2026, BSD-3-Clause) and styled through design tokens plus component styling hooks (--slds-c-* custom properties documented in each blueprint). SLDS 2, documented at lightningdesignsystem.com, is a new architecture that prioritizes CSS custom properties: it replaces design tokens with global styling hooks (--slds-g-*), which Salesforce describes as working with both SLDS 1 and SLDS 2 themes, and the Salesforce Cosmos theme is built on SLDS 2.The transition between the generations is the thing to plan around. SLDS 1 design tokens are deprecated: they still work in SLDS 1 themes but are not included in SLDS 2 themes. Component styling hooks are not yet supported in SLDS 2, and Salesforce's own comparison guidance recommends keeping an org on SLDS 1 themes for now if its custom components use them, while the tooling points the other way: the SLDS Linter is the current code-analysis tool for preparing components for SLDS 2, with automatic fixes applied in bulk, and the SLDS Validator scans markup against the system and recommends fixes. In Figma, SLDS 2 styling hooks appear as variables with the same semantic naming used in code, and Salesforce publishes an advanced SLDS 2 Figma library whose components map to live code. The SLDS 2 site also frames the new architecture as the foundation for Salesforce's agentic design system, with patterns for generative-AI experiences and Figma-to-code generation.Outside the platform runtime there is a React implementation, @salesforce/design-system-react on npm (version 0.10.65, checked October 2026, BSD-3-Clause), and the classic framework's GitHub repository (salesforce-ux/design-system) is now archived, with its terms split across files: BSD-3-Clause for the code, and a separate license file placing icons and images under Creative Commons Attribution-NoDerivatives 4.0 (CC BY-ND 4.0, checked October 2026), which requires attribution and does not permit distributing modified versions. The honest summary is that SLDS is a platform system first: its patterns for data tables, record pages, and dense enterprise workflows are the reference for CRM-style products, but its component model assumes the Salesforce platform in a way the other systems in this directory do not.
Primary Use Cases
- 1CRM and Sales Tools
- 2Human Resource Systems
- 3Supply Chain Management
- 4Government and Administrative Portals
- 5Apps built on the Salesforce platform (Lightning Experience, Lightning Web Components)
Technical Data
Guidelines
lightningdesignsystem.com (SLDS 2) and v1.lightningdesignsystem.com (SLDS 1): component blueprints with markup, styling hooks documented per component in SLDS 1, accessibility guidance (Salesforce states SLDS provides accessible markup as a foundation; the SLDS 1 new-design page cites WCAG 2.1 AA)
SLDS 1 package
@salesforce-ux/design-system on npm (version 2.264.3, checked October 2026), BSD-3-Clause; the classic CSS framework, styled with design tokens and component styling hooks
SLDS 2 theming
Global styling hooks: CSS custom properties in the --slds-g-* namespace that replace design tokens, work with SLDS 1 and SLDS 2 themes, and power themes such as Salesforce Cosmos; component styling hooks (--slds-c-*) are not yet supported in SLDS 2
React implementation
@salesforce/design-system-react on npm (version 0.10.65, checked October 2026), BSD-3-Clause; Salesforce Lightning Design System for React
Platform components
Base Lightning components implement the SLDS component blueprints and use SLDS styles; custom Lightning Web Components are built from blueprints where no base component fits
Tooling
SLDS Linter (current code-analysis tool; prepares components for SLDS 2, applies automatic fixes in bulk) and SLDS Validator (scans markup, validates it, recommends fixes)
Design files
SLDS 2 Figma library: styling hooks appear as Figma variables with the same semantic naming as in code, and components are documented as mapping one-to-one to live code
Source status
github.com/salesforce-ux/design-system (the classic SLDS repository) is archived, checked October 2026; the repository carries the BSD-3-Clause code license and LICENSE-icons-images.txt (CC BY-ND 4.0) for icons and images
License
BSD-3-Clause for the published code packages (@salesforce-ux/design-system and @salesforce/design-system-react, npm registry, checked October 2026); icons and images are licensed under Creative Commons Attribution-NoDerivatives 4.0 (LICENSE-icons-images.txt in github.com/salesforce-ux/design-system)
Editorial review
SLDS earns its place in this directory on the strength of one idea executed thoroughly: the blueprint. Where most systems ship a component library and describe it, SLDS specifies each component as framework-independent HTML and CSS, and then Salesforce's base Lightning components are implementations of those blueprints. A team building a custom Lightning Web Component works from the same specification the platform itself uses, which is why third-party Salesforce interfaces can match Lightning Experience closely enough that users cannot tell where the platform ends.
Two generations, one transition to plan The complication a 2026 adopter has to price in is that SLDS is mid-migration. SLDS 1 is token-based, and its tokens are now deprecated: they still work under SLDS 1 themes, but SLDS 2 themes do not include them. SLDS 2 replaces them with global styling hooks, CSS custom properties whose semantic names (the radius, spacing, and color roles) are shared with the SLDS 2 Figma library, where the same hooks appear as variables. That shared vocabulary is genuinely good design-to-code engineering. But the migration has an unfinished edge, and Salesforce says so itself: component styling hooks, the --slds-c-* properties documented in every SLDS 1 blueprint, are not yet supported in SLDS 2, and the official comparison guidance recommends staying on SLDS 1 themes if your components depend on them. The Linter and Validator tools exist precisely because this transition is mechanical enough to automate and large enough to need automating.
The honest costs First, the classic open-source repository is archived. The SLDS 1 CSS framework at version 2.264.3 is stable and complete, but teams adopting it standalone are adopting a finished artefact, and the living system is the one inside the Salesforce platform and the SLDS 2 documentation. Second, the licensing needs a careful read: the code packages are BSD-3-Clause, while icons and images sit under CC BY-ND 4.0, which requires attribution and bars distributing modified versions, so lifting SLDS visual assets wholesale is not the same thing as using its CSS. Third, the platform gravity is real. The patterns are the best reference in this directory for data tables, record pages, and console-style multi-tab work, but the component model assumes Lightning concepts throughout, and a non-Salesforce product borrows the look without the runtime that makes it coherent.
For teams building on Salesforce, none of that is a close call: SLDS is the native system, the blueprints are the contract, and the only real decision is where to stand on the SLDS 1 to SLDS 2 transition. For everyone else, read it as a pattern library for enterprise data work, and take the styling-hook architecture as the part most worth studying.
Directory Analysis & Suitability
Key Advantages
- Blueprint model: every component is a documented HTML and CSS specification, so custom components can match Lightning exactly, and the base Lightning components implement the same blueprints
- SLDS 2 global styling hooks work across SLDS 1 and SLDS 2 themes, and the same hooks appear as variables in the SLDS 2 Figma library with matching semantic names
- Migration tooling is part of the system: the SLDS Linter prepares components for SLDS 2 with bulk automatic fixes, and the SLDS Validator checks markup and recommends corrections
Considerations
- Two generations run in parallel, and the seams show: SLDS 1 design tokens are deprecated and absent from SLDS 2 themes, and component styling hooks (--slds-c-*) are not yet supported in SLDS 2
- The classic framework's GitHub repository is archived, so the SLDS 1 CSS package is a stable target to build on, not a moving one to follow
- The system assumes the Salesforce platform: base components, Lightning Web Components, and org theming are the native habitat, and standalone use means adopting the CSS framework without that runtime
Platform Compatibility
Web Environment
Primary surface, inside the Salesforce platform first: base Lightning components in Lightning Experience and Lightning Web Components, with the SLDS CSS framework (@salesforce-ux/design-system) and a React implementation (@salesforce/design-system-react) for web use.
Mobile & Touch
Salesforce's mobile app surfaces follow the same system; Salesforce publishes SLDS mobile guidelines, and the Linter and Validator check code against them.
Desktop Software
Desktop web is the design center: dense, multi-record CRM workflows in Lightning Experience are what the blueprints are specified for.