Storing Values Once with SCSS Variables

If you have ever changed a brand colour across a website and had to find every place it appeared, you already understand the problem variables solve. A hex code typed into forty different rules has to be updated forty times, and missing one leaves an inconsistency someone will eventually notice. Variables let you store a value once, give it a meaningful name, and reference that name everywhere. Change the value in one place and every use updates with it. This is the foundation that most of SCSS’s other features build on, so it is worth getting comfortable with.

What a Variable Is

An SCSS variable holds a value, a colour, a font stack, a measurement, a string, and lets you reference it by name throughout your stylesheets. The benefit shows up in three ways. Maintainability, because changing the value in one place updates it everywhere. Consistency, because using $brand-blue instead of a raw hex code guarantees the same blue appears every time. And readability, because a descriptive name explains intent in a way a raw value never can. $base-spacing tells you what a number is for. 16px on its own does not.

The Basic Syntax

A variable is declared with a dollar sign, followed by the name, a colon, and the value. You then use the name anywhere you would otherwise write the value:

$primary-color: #3498db;
$font-stack: 'Helvetica Neue', sans-serif;
$base-spacing: 16px;
body {
  font-family: $font-stack;
  color: $primary-color;
  margin: $base-spacing;
}

The body rule references three variables instead of three literal values. If the brand colour changes, you edit the $primary-color line and every rule using it follows.

Variables Inside Nested Selectors

Variables work naturally inside nested rules, which is useful for keeping related states consistent. A common pattern is deriving a hover state from the same variable that sets the base colour:

$button-bg: #e74c3c;
$button-padding: 10px;
.button {
  background-color: $button-bg;
  padding: $button-padding;
  &:hover {
    background-color: darken($button-bg, 10%);
  }
}

The hover state does not hardcode a separate, slightly darker colour. It derives one from $button-bg using the built-in darkenfunction. That means the hover colour is always related to the base colour. Change $button-bg and both the resting and hover states shift together, staying visually coherent without any manual recalculation.

Variables in Mixins

Variables and mixins work together. A mixin can take a variable as a parameter, often with a default value, so the same block of CSS can be customised at each call:

@mixin rounded($radius: 5px) {
  border-radius: $radius;
}
.box {
  @include rounded(10px);
}

Here .box overrides the default radius with 10px, but a selector that called rounded() with no argument would get the 5px fallback. This is where variables stop being just storage and start enabling reusable, parameterised logic.

A Note on Changing Variables in Different Contexts

You might expect to redefine a variable inside a media query and have it cascade outward, like this:

$base-font-size: 16px;
body {
  font-size: $base-font-size;
}
@media (min-width: 768px) {
  $base-font-size: 18px;
  body {
    font-size: $base-font-size;
  }
}

This works, but it is important to understand why, because it is easy to get wrong. SCSS variables are resolved at compile time, not in the browser. They are static within their scope. The reassignment inside the media query takes effect because it happens before the font-size line that uses it, in compile order. If you used the variable before reassigning it, you would get the old value. SCSS variables are not live values the browser tracks. They are placeholders the compiler fills in as it reads top to bottom. For genuinely dynamic, runtime-responsive values, CSS custom properties (the native --variablesyntax) are the better tool, because the browser evaluates those live.

Working with Variables Well

Centralise your variables in a dedicated file, conventionally _variables.scss, and import it at the top of your main stylesheet. This gives you a single place to see and adjust every value your design depends on. When a designer asks to nudge the spacing scale or swap a colour, you know exactly where to go.

Name variables descriptively. $primary-color and $base-spacing document themselves. $blue or $x force the reader to guess at intent and meaning.

Use the !default flag for values you want to be overridable:

$primary-color: #3498db !default;

The !default flag sets a value only if the variable has not already been defined elsewhere. This is what lets a library ship sensible defaults that a project importing it can override, without editing the library’s own files.

Group variables by purpose. Keep colours together, fonts together, spacing together. A _variables.scss organised into clear sections is far easier to navigate than a flat list of unrelated values.

Finally, do not turn every value into a variable. Variables earn their place when a value is reused, carries meaning, or is likely to change. A one-off value used in a single rule rarely benefits from being abstracted, and over-variableising makes code harder to follow rather than easier.

The Takeaway

Variables are the simplest and most fundamental of the SCSS tools, and they underpin nearly everything else. They store a value once under a meaningful name so it can be reused, kept consistent, and changed in a single edit. The one concept that catches people out is that SCSS variables are resolved when the stylesheet compiles, not while the page runs, which is why they behave as static placeholders rather than live values. Keep them centralised, named clearly, and grouped by purpose, and they become the reliable single source of truth that a maintainable stylesheet is built on.

See you soon