Breakpoint per le Media Query di Bootstrap 3

In una subentranza su un progetto legacy per un'azienda del settore servizi, mi sono trovato davanti a un gestionale web la cui interfaccia era costruita su Bootstrap 3, con sopra una stratificazione di CSS custom scritto da almeno tre sviluppatori diversi negli anni. Il compito era aggiungere una vista responsive a una sezione nuova, e per farlo dovevo intervenire sulle media query esistenti senza rompere il resto. La prima cosa che ho fatto è stata cercare i breakpoint esatti del framework, perché modificare la responsività di un layout Bootstrap senza conoscere i punti in cui il suo grid cambia comportamento significa lavorare alla cieca e introdurre regressioni a ogni salvataggio.

Il problema è che la lista di breakpoint che si trova più spesso in rete, e che era anche nella documentazione interna di quel progetto, era sbagliata: mescolava le dimensioni tipiche dei dispositivi (320px per un iPhone, 480px per uno smartphone generico) con i veri breakpoint della griglia di Bootstrap 3, che sono altri. È un errore che costa ore, perché scrivi una media query a 480px convinto di intercettare il passaggio di colonna del framework, e invece quel passaggio avviene a 768px, quindi la tua regola non fa quello che ti aspetti. Mettiamo quindi i valori giusti, e poi parliamo del contesto che conta ancora di più: cosa significa, nel 2026, avere ancora Bootstrap 3 in produzione.

TL;DR

Breakpoint reali della griglia di Bootstrap 3: 768px (sm), 992px (md), 1200px (lg); sotto i 768px è la fascia xs. Sono 3 soglie, non 5 (le 320/480 che girano in rete non sono breakpoint del framework).
Variabili sorgente: @screen-sm-min, @screen-md-min, @screen-lg-min. In max-width sottrai 1px: 767, 991, 1199.
Contesto: Bootstrap 3 è fuori supporto dal 2019 e dipende da jQuery. Questi breakpoint servono a manutenere l'esistente, non a costruire il nuovo.
Oggi: Bootstrap 5.3 ha 6 fasce (576/768/992/1200/1400) e la soglia 768 ha cambiato significato; per il nuovo, valuta i container query CSS.

Quali sono i breakpoint reali della griglia di Bootstrap 3?

Bootstrap 3 ha quattro fasce di griglia (i grid tier xs, sm, md, lg) governate da tre soglie, non da cinque. Il framework è mobile-first, quindi le soglie sono espresse come min-width: una regola si applica a quel breakpoint e a tutti quelli superiori. I tre valori che fanno scattare il cambio di comportamento delle colonne sono 768px, 992px e 1200px. Tutto ciò che sta sotto i 768px è la fascia xs (extra small, smartphone), che non ha un proprio min-width perché è il punto di partenza del mobile-first.

/* Bootstrap 3 - i breakpoint REALI della griglia (mobile-first, min-width) */

/* xs: extra small, < 768px -> nessuna media query, e' la base */

/* sm: small, tablet in verticale */
@media (min-width: 768px) { /* ... */ }

/* md: medium, desktop piccoli */
@media (min-width: 992px) { /* ... */ }

/* lg: large, desktop ampi */
@media (min-width: 1200px) { /* ... */ }

Questi numeri non sono arbitrari: nel codice sorgente di Bootstrap 3 sono le variabili Less (e Sass nella versione community) @screen-sm-min: 768px, @screen-md-min: 992px, @screen-lg-min: 1200px. Se il tuo progetto usa la build sorgente del framework e non il CSS compilato, la cosa corretta da fare non è scrivere i pixel a mano nelle tue media query, ma riferire quelle stesse variabili, così che se un giorno qualcuno personalizza le soglie nella configurazione del framework, il tuo CSS custom resti allineato invece di divergere silenziosamente. Hardcodare 768px in venti punti diversi del foglio di stile è esattamente il tipo di debito che mi sono trovato a districare in quel progetto: bastava cambiare una soglia per dover inseguire decine di occorrenze sparse.

Se ti serve anche il verso opposto, cioè intercettare quando si scende sotto una soglia (utile per nascondere o ridisporre elementi sui dispositivi piccoli in un'ottica desktop-first mista), Bootstrap 3 nel suo sorgente sottrae un pixel al breakpoint superiore per evitare sovrapposizioni: la fascia xs come max-width è 767px, la sm è 991px, la md è 1199px. È un dettaglio che conta, perché scrivere max-width: 768px invece di 767px crea una zona di un pixel in cui due media query opposte sono entrambe attive, con risultati visivi imprevedibili proprio sul confine.

Come si modifica la responsività di un layout Bootstrap 3 senza romperlo

Conoscere i breakpoint è il presupposto, ma la differenza fra un intervento pulito e una regressione la fa il metodo con cui scrivi il CSS custom sopra il framework. Il principio guida è non combattere la cascata di Bootstrap, ma allinearsi a essa. Il framework è mobile-first, quindi anche il tuo CSS custom deve esserlo: parti dallo stile base valido per gli schermi piccoli, poi aggiungi le media query min-width che progressivamente ampliano il layout sulle fasce superiori. Scrivere prima la regola desktop e poi tentare di "tornare indietro" sui dispositivi piccoli con una valanga di sovrascritture è il modo più rapido per ritrovarsi con regole che si contraddicono.

La seconda regola è usare esattamente le soglie del framework, 768px, 992px e 1200px, e non valori intermedi inventati. Se inserisci una tua media query a 850px, crei un punto di rottura che il grid di Bootstrap non conosce: le colonne del framework restano nella loro configurazione sm mentre il tuo CSS custom cambia, e il risultato è un layout disallineato in una fascia di larghezze. Ogni tua soglia deve coincidere con una soglia del framework, a meno che tu non stia deliberatamente gestendo un componente che vive fuori dalla griglia.

/* Override mobile-first allineato ai breakpoint del framework */
.pannello-laterale {
  margin-bottom: 1rem; /* base: schermi piccoli, impilato */
}

@media (min-width: 992px) { /* fascia md: affianca a partire dai desktop piccoli */
  .pannello-laterale {
    margin-bottom: 0;
    border-left: 1px solid #e0e0e0;
  }
}

La terza regola riguarda la specificità: non risolvere i conflitti a colpi di !important, che rende il foglio di stile sempre più difficile da manutenere a ogni intervento successivo. Meglio aumentare la specificità del selettore in modo controllato, agganciandolo a un contenitore della tua sezione, così che le tue regole vincano su quelle del framework solo dove vuoi tu e non ovunque. E infine la verifica: gli strumenti per sviluppatori del browser permettono di emulare le larghezze, ed è il primo controllo, ma il test che conta davvero si fa sul confine esatto dei breakpoint (a 767 e 768 pixel, a 991 e 992) e su dispositivi reali, perché è proprio sul pixel di confine che emergono le sovrapposizioni che in emulazione passano inosservate. Nel progetto da cui sono partito, la maggior parte delle regressioni storiche del CSS custom nasceva esattamente da media query scritte a soglie arbitrarie e testate solo ridimensionando la finestra del browser su un monitor desktop.

Perché sapere i breakpoint di Bootstrap 3 non significa che dovresti usarlo

Qui devo essere onesto sul contesto, perché è la parte che fa la differenza fra una consulenza seria e un copia-incolla di numeri. Bootstrap 3 è uscito nel 2013 e ha raggiunto la fine del supporto ufficiale nel 2019. Da allora non riceve né correzioni di sicurezza né fix di compatibilità. Questo ha due conseguenze concrete per chi ce l'ha ancora in produzione. La prima è la dipendenza da jQuery: Bootstrap 3 richiede jQuery per tutti i suoi componenti JavaScript (modali, dropdown, tooltip), e trascinarsi una versione datata di jQuery significa trascinarsi una superficie di rischio che andrebbe almeno tenuta sotto controllo. La seconda è la divergenza dai dispositivi reali: i breakpoint del 2013 ragionavano su un parco device che non esiste più, e oggi una griglia che si ferma a 1200px non considera gli schermi molto ampi che sono ormai comuni.

Su quella dipendenza da jQuery vale la pena un controllo concreto, perché è il punto dove un front-end datato diventa un problema di sicurezza e non solo di estetica. Bootstrap 3 richiede una linea di jQuery ormai vecchia, e le versioni storiche della libreria hanno avuto vulnerabilità note, tipicamente di cross-site scripting, che in un applicativo esposto contano. Il minimo sindacale, finché il front-end resta su Bootstrap 3, è sapere quale versione esatta di jQuery sta servendo, verificarla contro le vulnerabilità note e valutare se aggiornarla all'ultima release della sua linea senza rompere i componenti del framework. È un intervento contenuto che riduce il rischio mentre si pianifica la modernizzazione vera, e rientra nello stesso approccio di audit che applico a qualsiasi dipendenza datata di un progetto ereditato.

Tutto questo non vuol dire "riscrivi tutto domani". Significa che sapere i breakpoint di Bootstrap 3 è una competenza di manutenzione, non di costruzione: serve per intervenire in sicurezza su ciò che esiste, mentre si pianifica con calma un percorso di modernizzazione. È esattamente l'approccio che applico al codice legacy in generale, dove la priorità è non rompere ciò che funziona mentre lo si porta gradualmente verso uno stato sostenibile. Se ti riconosci nella situazione di un'interfaccia datata che nessuno osa toccare, nel mio profilo professionale trovi l'esperienza concreta sulla modernizzazione incrementale di applicativi e front-end ereditati, senza riscritture big-bang che bloccano il business.

Cosa è cambiato nei breakpoint con Bootstrap 5

Se il percorso di modernizzazione passa per un aggiornamento del framework, è bene sapere che i breakpoint non sono rimasti gli stessi, quindi un porting non è mai un semplice cambio di file CSS. Bootstrap, la cui versione corrente è la linea 5.3, ha sei fasce invece delle quattro della versione 3, e le soglie sono diverse. Come riporta la documentazione ufficiale sui breakpoint di Bootstrap, i valori attuali, definiti nella mappa Sass $grid-breakpoints, sono xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px, xxl: 1400px.

// Bootstrap 5.3 - la mappa Sass dei breakpoint
$grid-breakpoints: (
  xs: 0,
  sm: 576px,
  md: 768px,
  lg: 992px,
  xl: 1200px,
  xxl: 1400px
);

Due differenze saltano all'occhio e sono entrambe trappole in un porting. La prima: è comparsa la fascia sm a 576px, che in Bootstrap 3 non esisteva, e la xxl a 1400px per gli schermi molto ampi. La seconda, più insidiosa: la soglia 768px, che in Bootstrap 3 era il confine sm (l'inizio dei tablet), in Bootstrap 5 è il confine md. Lo stesso numero ha cambiato significato fra le due versioni. Chi porta meccanicamente le media query da 3 a 5 confidando nei pixel, senza accorgersi che la semantica delle fasce è slittata, ottiene un layout che sembra giusto su desktop e si rompe in modo sottile sui tablet. È il genere di regressione che non si nota in fase di sviluppo su un monitor grande e che esplode in produzione sui dispositivi reali degli utenti. Un altro cambiamento di sostanza è che Bootstrap 5 ha eliminato la dipendenza da jQuery, riscrivendo i componenti in JavaScript nativo, il che è di per sé una buona ragione per aggiornare, ma comporta anche di rivedere ogni pezzo di codice custom che si appoggiava a jQuery.

Come si scrive il responsive oggi, oltre i breakpoint del framework

C'è una ragione più profonda per cui rivisitare un articolo sui breakpoint di un framework del 2013 è l'occasione per un cambio di prospettiva: il modo in cui si costruisce il responsive è cambiato alla radice, e oggi spesso non serve affatto un framework di griglia. Le media query basate sulla larghezza del viewport, che sono il fondamento di Bootstrap, hanno un limite concettuale: rispondono alle dimensioni dello schermo, non a quelle dello spazio in cui un componente vive davvero. Un componente card che deve disporsi su una colonna dentro una sidebar stretta e su due colonne dentro l'area principale, alla stessa larghezza di viewport, con le sole media query non si può fare in modo pulito.

La risposta moderna sono i container query, che permettono a un componente di adattarsi alla larghezza del suo contenitore invece che a quella della finestra. Sono ormai supportati in modo ampio da tutti i browser principali e sono passati da novità a strumento di produzione affidabile, come documenta la pagina di riferimento di MDN sui container query. Insieme ad altre primitive native come clamp() per le dimensioni fluide, le custom property CSS per i valori dinamici e i layout intrinseci con Grid e Flexbox, permettono di costruire interfacce responsive che in molti casi non hanno bisogno di un framework di griglia esterno e del peso che si porta dietro.

/* Responsive moderno: il componente si adatta al contenitore, non al viewport */
.card-list { container-type: inline-size; }

@container (min-width: 480px) {
  .card { display: grid; grid-template-columns: 1fr 2fr; }
}

Questo non significa che Bootstrap sia da buttare: per una dashboard interna o un gestionale dove la velocità di sviluppo conta più del peso della pagina, una versione aggiornata del framework resta una scelta legittima e produttiva. Significa che la decisione fra "aggiorno il framework" e "passo a CSS nativo" va presa guardando al progetto, non per inerzia. Su come si imposta un layout pulito con le primitive moderne di CSS ho raccolto qualche indicazione pratica nell'articolo sui consigli utili per il layout in CSS3, e quando il front-end è agganciato a un backend Laravel, l'approccio integrato che evito di frammentare in mille API lo descrivo nell'articolo su Inertia.js con Laravel e Vue 3, perché la scelta del responsive non vive isolata dall'architettura applicativa.

Avere a portata di mano i breakpoint corretti di Bootstrap 3, quelli reali a 768, 992 e 1200 pixel e non le dimensioni dei dispositivi che spesso li sostituiscono per errore, è utile e resta utile finché esistono progetti che lo usano. Ma il valore vero di questa lista, nel 2026, è capire dentro quale cornice la stai usando: se è per manutenere in sicurezza un'interfaccia che porta ancora visite e fatturato, è la competenza giusta; se è per costruire qualcosa di nuovo, allora i breakpoint da guardare sono altri, quando non addirittura un paradigma diverso come i container query. Se hai un front-end datato che fatica sui dispositivi moderni e vuoi capire se conviene aggiornarlo, riscriverlo o lasciarlo dov'è, contattami per un confronto diretto: la scelta giusta dipende da quanto quel codice vale per il tuo business, e quasi mai è quella che sembra ovvia a prima vista.