Bootstrap 6 defaulting to 14px instead of 16px for the $font-size-base

[pricop]

Is there a reason in particular on why Bootstrap 6 is going to a different $font-size-base in scss/_variables.scss than the browser's default one which is 1rem on all the browsers and operating systems I can think of.

I noticed this while looking at the v6 docs, the examples feel off on pretty much every component I've checked (badges, cards, inputs, buttons), they all look so small.

Tailwind, BS5, and BS4 all default to 1rem (16px basically).

Is BS6 going to default to 1rem moving forward or was this a temporary change that was left to 14px?

Personally I believe, at least for the sake of accessibility, that the default $font-size-base should be set to 1rem. I know this is configurable, but the defaults matter too.

Originally posted by @pricop in #41740

[pricop]

Update: this change reintroduces a plethora of older issues (such as this one: #35553), and creates new ones too. Since the $font-size-base is now 14px, the -sm classes/calculations, their computed values will now be at 12.25px because the ratio of -sm is .875, so pixel divisions start happening.

This can be easily observed on normal DPI screens, see:

Furthermore this also affects -xs classes/calculations too, since their computed values will now be at 10.5px, because the ratio of -xs is .75.

In this current form, #35553 will happen by default on Bootstrap on pretty much every component.

My proposal is to switch back to $font-size-base set to 1rem so that sm becomes 14px, and xs becomes 12px, so no pixel division happens. And if the preferred way is to have smaller texts in dropdowns and other elements, we can simply apply the $font-size-sm to them instead of the $font-size-base, that way you can keep the text smallers, without having any clamping issues.

Alternatively, if you really want to stick with $font-size-base set to 14px, to avoid line clamping, will need to choose different ratios for sm and xs so that no pixel divisions happen.

[nextgenthemes]

I already commented in this in the code directly, I also hope it's just a temp leftover because it makes no sense to me. Not the 14px part but the hard-coding it instead of having it dynamic. If I understand this correctly this kills users font size setting on browsers and the entire point about rem.

[mdo]

Yeah this was me trying to play with a few things. In my experience, most apps these days use 14px for their components, so I've been trying that out as the base font-size as 16px default buttons feels rather large to me. I may still ship something like this, but without the modification to the base font-size. TBD.

[pricop]

I believe you should take into consideration the context of those apps.

Design trends come and go, in 2-4 years we might be defaulting back to 16px.

Most of the apps that are practicing 14px (and even frameworks, such as shadcn ui), have a lot of components ready made for large/complex dashboards, such as the likes of: ui.shadcn.com, catalyst.tailwind.com, etc, so they kinda have to cather to that, this is especially true since they don't provide "-lg", "-base", and "-small" variants.

It's much easier to just use "small" class to bring everything down to 14px, than vice-versa, due to how padding works (this is what catalyst is doing).

By designing the paddings to work with 16px, when applying small on an element, the padding won't feel too small.

By contrast, if paddings will be calculated for 14px elements, applying the base font size utility won't be sufficient, and additional padding will need to be added.

Yes, we'll have the option to tinker with paddings, as they're variables, but you can reduce the overhead for when this will go live.

Another thing that I've noticed is with inputs.

BS5 practiced 38px input height, with a 16px font size, with the same height & size for buttons.
BS6 went to 40px input height, and 14px in font size (smaller font to read, larger paddings), while buttons have shrinked in height considerably. I don't see how inline forms will work with the current input height, the paddings for buttons will be exaggerated at 40px.

I'd be willing to contribute and/or provide feedback if there's a thread where you're discussing certain design decisions. I understand that this is still in very early stages, and you're still experimenting/testing, which is the right thing to do.

P.S. I love the direction BS6 is going with the new OTP inputs, chip inputs, inverted, date range pickers, button variants, etc. The world really needs a framework that doesn't require half of the npm repository (and react) just to have a functional webpage 😅.

[mdo]

I really really appreciate the thoughtful and critical response here. Please don’t hesitate to keep it coming. The delivery and approach is well received :).

Regarding ongoing feedback and general questions/ideas, I’ve opened https://github.com/orgs/twbs/discussions/42090 to consolidate v6-dev feedback. You can continue to post things there or even in issues/PRs if you like.

I’ll swing back and see about updating the base font-size and those input sizes. I do agree some things have felt big while others have felt small. In general I’m trying to figure out what the new visual language looks like for Bootstrap in 2026. I really feel like leaning into more opinionated styles with easy overrides is the path forward.

I’m also in a slight holding pattern on Sass stuff and would love feedback on an idea I had to consolidate our approach to Sass/CSS customization. See #41983. That’ll really affect how much components continue to change internally.

Let me know what you think of all that and any other ideas/comments.

[pricop]

Thank you @mdo - I'll move over to https://github.com/orgs/twbs/discussions/42090 with some proposals. Feel free to close this issue if you'll be actively looking into the discussion thread. I'd rather not open a new issue for every suggestion that I have. I'll be offering feedback soon, as my time allows.

[mdo]

Updated in #42119.