The Difference Between Background and Surface Tokens
Discover the key differences between 'background' and 'surface' in color token naming and practical tips to choose the right one for your own.
When defining color tokens in a design system, you often need to name the layers behind your content. Should you use background or surface?
At first glance, they seem similar: both describe something “behind” the content. But they carry different mental models:
Background usually refers to a flat, foundational canvas.
Surface implies a tangible layer where components rest, often linked to elevation or depth.
Choosing one over the other shapes how your team thinks about hierarchy, theming, and layering.
What "background" Usually Represents
In many design systems, background is the straightforward choice. It maps easily to CSS (background-color) and is often used for:
Global app backgrounds
Page or section containers
Simple, flat layers without elevation
It's immediately intuitive to both designers and developers, reducing friction during team collaboration. Everyone understands what a background is without needing further explanation.
Moreover, "background" is straightforward to implement across various platforms and frameworks. Whether you're using CSS, iOS, Android, or other environments, the concept maps cleanly to native properties.
For simpler design systems that don't heavily rely on elevation or layering concepts, "background" provides sufficient semantic meaning without complicating the mental model.
Some Limitations
Despite its simplicity, the term "background" can become problematic in more sophisticated interfaces. In systems with multiple layers of depth, simply calling everything a "background" doesn't provide enough distinction between different elevation levels.
There's also the potential for naming collisions and confusion. For instance, "background" might refer to either decorative background images or to UI color layers, creating ambiguity in documentation and implementation.
What "surface" Usually Represents
Surface represents more than a flat canvas—it suggests a layer that holds content. This concept thrives in systems where elevation, shadow, and layering are important.
Common uses include:
Cards and panels for containing content
Modal dialogs that float above the main content
Dropdown menus and popovers
Bottom sheets in mobile interfaces
Sidebars and navigation drawers
Using "surface" in your design system has several advantages. It effectively communicates hierarchy and physicality in your interface, creating a more intuitive mental model for how elements relate to each other in space. This terminology works naturally with concepts like elevation, shadows, and interactive states, making it easier to describe complex layering relationships.
Furthermore, the surface concept clearly differentiates between the global page background and the various component-level layers that sit on top of it, which can lead to more consistent implementation across your product.
Some limitations
However, there are some drawbacks to consider. Teams that aren't familiar with layered design metaphors might find the concept more abstract and harder to grasp than the straightforward "background" term.
There's also a practical implementation challenge: unlike "background," which maps directly to CSS's background-colorproperty, there's no native surface-color property in CSS, requiring additional documentation and convention-setting within your team.
How to Decide Which to Use
When to Prefer “background”
Use "background" tokens when your design system is flat and simple without focusing on depth. This works best when your colors are mostly used for layouts and pages.
When to Prefer “surface”
Use surface tokens when your system includes elevation, shadows, or layered tones. This fits naturally where cards, sheets, and modals appear above other elements. Choose surface to highlight spatial relationships between content and containers—focusing on where content exists in the hierarchy rather than just what's behind it.
Can You Use Both?
Yes, many mature systems use both approaches. Typically, reserve "background" for global, layout-level elements (app and page backgrounds) and "surface" for interactive or elevated components (cards, dialogs). This clear separation reduces ambiguity and makes interface hierarchy more explicit for the team.