Generate Bootstrap 5 theme colors from your brand: the $theme-colors SCSS map for build-time customization and the –bs-* CSS variables for runtime (5.3+). Optionally re-derive the success, danger, warning and info state colors in your brand’s own chroma, with white-text contrast measured and reported on every role before you ship it.
Settings
Generated locally in your browser — your settings and results never leave this page.
Theming Bootstrap without fighting it
Bootstrap’s visual identity flows from six theme colors — primary, secondary, success, danger, warning, info — and the framework provides two sanctioned override points: the $theme-colors Sass map at build time (every component recompiles around your values) and the --bs-* custom properties at runtime (5.3+, no toolchain required). Everything else is fighting the framework. This generator emits both artifacts from your brand colors, correctly formatted, ready to paste.
The harmonization option
Stock Bootstrap state colors carry their own personality — a specific green, a specific red — that can sit awkwardly beside a distinctive brand. The harmonize toggle re-derives success, danger, warning and info at their conventional hues (recognition depends on green meaning success) but at your primary’s chroma level in OKLCH: alerts that are unmistakably alerts, unmistakably yours. Off by default, because stock colors are also a legitimate choice — familiarity has UX value.
The contrast column earns its place
Bootstrap paints white text over theme colors in buttons and badges, and its own default warning yellow is the cautionary tale — white-on-#ffc107 measures under 2:1. The per-role measured column catches your equivalents before shipping: roles failing white text should either darken or flip to dark text (Bootstrap’s color-contrast() function automates the flip when the Sass map feeds it honest colors). Measurement first, framework machinery second.
Integration notes
Sass route: define the map before @import "bootstrap"; the cascade of derived shades (-subtle, -emphasis in 5.3) regenerates automatically. Runtime route: scope --bs-primary and friends to :root or a theme class; components consume them live. Custom roles append to the same map and materialize as full component variants. And the same brand colors feed the Tailwind Theme Generator when the stack differs — the workflow is deliberately parallel.
Beyond colors: what theming does not cover
Scoping honesty: the six theme colors recolor Bootstrap, they do not restyle it. Radii, shadows, spacing and typography live in their own Sass variables ($border-radius, $box-shadow, the RFS scale), and brand transformations usually want a pass over those too. The efficient order: colors first (this page — largest visual impact per line), then radius and shadow language, then type. Teams porting an existing identity can mine their design tokens for all three layers; the adjacent Design Token Generator produces the non-color scaffolding in compatible SCSS.
How to use the Bootstrap Theme Color Generator
- Pick your primary (and optionally secondary) brand colors.
- Optionally re-derive the state colors in your brand chroma.
- Copy the SCSS map for build-time theming or the –bs-* variables for runtime.
Frequently asked questions
How do I change Bootstrap's theme colors properly?
Two supported routes, both generated here: override the $theme-colors SCSS map before importing Bootstrap (build-time – all components recompile around your colors) or set the –bs-* custom properties at runtime (5.3+, no build needed, instant theming). The SCSS route is the thorough one; the variables route the flexible one.
What does the "derive state colors from primary" option do?
It regenerates success, danger, warning and info at their conventional hues (green/red/amber/cyan) but carrying your primary's chroma level in OKLCH – so alerts feel like your product's alerts instead of stock Bootstrap glued onto a brand. Semantic hue recognition survives; the vividness becomes yours.
Why does the tool measure white-text contrast per role?
Because Bootstrap's buttons and badges put white (or auto-chosen) text on these fills, and stock Bootstrap itself has famous marginal cases (warning yellow). The measured column tells you before shipping which roles need dark text – Bootstrap's color-contrast() SCSS function can then do the right thing with correct inputs.
Do I need to regenerate anything else after changing $theme-colors?
The map drives everything – buttons, alerts, badges, borders, subtle backgrounds – via Sass loops, so no. Two follow-ups worth checking: link color (independent $link-color variable) and any hardcoded hexes your own CSS accumulated against the old theme.
Does this work for Bootstrap 4?
The SCSS map approach, yes (v4 has $theme-colors too); the –bs-* runtime variables are 5.2/5.3+ territory. The generated map syntax is compatible with both; the variables block states its version requirement.
Can I add more roles than the six?
Bootstrap merges whatever keys you put in the map – add "tertiary": #… and .btn-tertiary etc. materialize. Generate the base six here, append custom roles in the same format, keep the naming semantic.
How does this relate to the Tailwind Theme Generator on this site?
Same job, different framework dialect: that one emits Tailwind v3 config / v4 @theme, this one SCSS maps and –bs-* variables. Both derive from your brand color with measured contrast – pick your framework's page and the workflow is identical.
