Runtime Theming Without Rebuilding Bootstrap
Bootstrap remains a go-to UI framework for its predictability, but its opinionated nature can become a hurdle when you need styles to change dynamically at runtime. The framework’s recommended approach—pre-generating a stylesheet per theme and swapping them—works fine for fixed themes, but falls short when users need to define their own colors, such as per-account branding in a multi-tenant SaaS app.
Compiling new Sass stylesheets on the fly is one option, but it requires server-side build tooling and coordination with back-end teams—overkill if you just want to tweak a primary or secondary color. A more direct path exists if you can rely on CSS variables (meaning no Internet Explorer 11 support is needed). The catch: Bootstrap’s compiled output hardcodes most color values as hex literals, and while the stylesheet defines a robust set of CSS variables in :root, those variables are mostly for end-user consumption. Only a handful are referenced throughout the rest of the CSS, so simply overriding the variable list has little effect.
The solution that works is to inject CSS variables into the compiled stylesheet after the fact—using find-and-replace on the static color values. It’s not subtle, but it sidesteps the brittleness of forking Bootstrap’s source, and it works with the server-side generation model the framework expects.
Finding the Values to Replace
Your compiled Bootstrap CSS starts with the full set of default variables in :root. Those entries are the source of truth for the values you’ll want to swap out. For instance, --bs-primary holds the standard Bootstrap blue, and that same literal hex value appears throughout the stylesheet wherever the primary color is used.
If your build pipeline uses a tool like Gulp, the task that compiles the stylesheet is where the replacement logic belongs. The transformation should run at the very end of the pipe—after compilation, but before the file is written to disk.
Injecting the Variable
Using a package like gulp-replace, the process is straightforward. Add the replacement pipe after your Sass compilation step:
You’re swapping every occurrence of the static color with a CSS variable reference. Take care to note that the replacement catches both the primary color and any color of the same name in the palette—so “blue” and “primary” will both change. If you need them to be independently configurable, redefine the underlying Sass variables ($blue and $primary) to different values before compilation, then perform separate find-and-replace operations on each resulting hex value.
After compiling, your stylesheet will reference the new CSS variable everywhere the old color appeared. Now you need to provide a value for that variable. A simple inline :root block in the page’s head is all it takes:
From there, you can offer a color picker or profile setting that emits a custom :root block with the user’s chosen override. The same pattern extends naturally to other theme values—secondaries, alerts, and so on—by repeating the find-and-replace for each color you need to expose. The result is full runtime theming control without any recompilation, new stylesheet generation, or deployment gymnastics.
Why Not Wait for Better Variable Support?
Improved runtime variable support has been under discussion for Bootstrap, and version 5.2 introduced broader CSS variable usage directly in the framework. For those on 5.2 or newer, many overrides work out of the box. But if you’re on an older release, or need control beyond what the core variables expose, this replacement technique fills the gap cleanly—as long as you accept that it’s a deliberate, slightly hacky means to a practical end.
This isn’t the most polished approach, but it solves a recurring problem with minimal infrastructure changes. Until Bootstrap provides a first-class, runtime-friendly theming API, injecting variables into the compiled stylesheet remains a dependable fallback for dynamic, user-defined themes.
