Responsive design means a site adapts cleanly to whatever screen it is viewed on, from a small phone to a large desktop monitor, and Bootstrap builds this in through a set of breakpoints, which are specific screen-width thresholds that trigger layout changes.

The main breakpoints

  • sm, roughly 576 pixels and up, covering larger phones.
  • md, roughly 768 pixels and up, covering tablets.
  • lg, roughly 992 pixels and up, covering laptops.
  • xl, roughly 1200 pixels and up, and xxl beyond that, covering large desktop monitors.

Mobile-first thinking

Bootstrap is built mobile-first, meaning a class with no breakpoint suffix, such as col-12, applies at every screen size unless overridden. A class with a breakpoint, such as col-md-6, only takes effect from that width upward, layering larger-screen adjustments on top of a solid small-screen default rather than the other way around.

A responsive column example

<div class="col-12 col-md-6 col-lg-4">Content</div>

This element takes the full row on a phone, half the row on a tablet, and one third of the row on a laptop or larger, all from a single line of markup with no separate stylesheets for each device.

Hiding and showing elements responsively

<div class="d-none d-md-block">Visible from tablets upward</div>

Display utilities combine a breakpoint with a display value, so an element can be hidden entirely on phones but shown as a block once the screen grows large enough, useful for things like a sidebar that only makes sense once there is enough horizontal space for it.

Container widths at each breakpoint

A standard .container does not simply stretch to fill the screen; instead it snaps to a fixed maximum width at each breakpoint, growing in steps rather than continuously, which keeps line lengths of text comfortable to read even on very wide monitors.

A common responsive mistake

Building a layout by testing only at one browser width, then assuming it works everywhere, is one of the most frequent responsive design mistakes. Resizing the browser window continuously while developing, or using a browser's device toolbar to simulate different phones and tablets, catches awkward breakpoints far earlier than waiting for a real user to report a broken layout on their device.

Testing as you build

Treating responsiveness as something checked continuously while building a page, rather than a final pass done right before launch, consistently produces a more polished result, since small layout issues are far easier to fix the moment they appear than after an entire page has been built around an assumption that turned out to be wrong.