---
title: "Breakpoint per le Media Query di Bootstrap 3"
description: "I breakpoint reali delle media query di Bootstrap 3, perché spesso vengono ricordati male, e cosa fare oggi che Bootstrap 3 è fuori supporto dal 2019."
canonical: "https://www.mauriziofonte.it/blog/post/boostrap-3-media-query-breakpoints.html"
author: "Maurizio Fonte"
date: "2026-02-13T11:34:35+01:00"
modified: "2026-06-15T18:01:13+02:00"
section: "Frontend"
tags: ["Frontend"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Frontend](https://www.mauriziofonte.it/blog/cat/frontend.html)

# [Breakpoint per le Media Query di Bootstrap 3](https://www.mauriziofonte.it/blog/post/boostrap-3-media-query-breakpoints.html)

Venerdì 13 Febbraio 2026, alle 11:34 ![Breakpoint per le Media Query di Bootstrap 3](https://www.mauriziofonte.it/image/000330200-boostrap-3-media-query-breakpoints.jpg)

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.

```css
/* 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.

```css
/* 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](https://www.mauriziofonte.it/pages/about) 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](https://getbootstrap.com/docs/5.3/layout/breakpoints/), i valori attuali, definiti nella mappa Sass `$grid-breakpoints`, sono `xs: 0`, `sm: 576px`, `md: 768px`, `lg: 992px`, `xl: 1200px`, `xxl: 1400px`.

```scss
// 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](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries). 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.

```css
/* 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](https://www.mauriziofonte.it/blog/post/consigli-utili-per-layout-css3.html), 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](https://www.mauriziofonte.it/blog/post/inertia-js-laravel-vue3-fullstack-senza-api-rest.html), 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](https://www.mauriziofonte.it/pages/contattami): la scelta giusta dipende da quanto quel codice vale per il tuo business, e quasi mai è quella che sembra ovvia a prima vista.

Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [« Articolo precedenteService mesh con Istio per microservizi PHP: osservabilità e sicurezza senza codice applicativo13 Febbraio 2026](https://www.mauriziofonte.it/blog/post/service-mesh-istio-microservizi-php-osservabilita-sicurezza.html)[Articolo successivo »OpenTelemetry per PHP: distributed tracing end-to-end senza vendor lock-in16 Febbraio 2026](https://www.mauriziofonte.it/blog/post/opentelemetry-php-distributed-tracing-senza-vendor-lock-in.html)

### Articoli correlati a Breakpoint per le Media Query di Bootstrap 3

- [Automazione test di regressione visuale con Playwright per applicazioni Laravel](https://www.mauriziofonte.it/blog/post/automazione-test-regressione-visuale-playwright-applicazioni-laravel.html)

  Un refactoring CSS su un gestionale Laravel aveva rotto la visualizzazione di 12 componenti nessuno se ne era accorto fino alle segnalazioni · 18 Febbraio 2026

  ![Automazione test di regressione visuale con Playwright per applicazioni Laravel](https://www.mauriziofonte.it/image/003100070-automazione-test-regressione-visuale-playwright-applicazioni-laravel.jpg)
- [Prompt caching workspace-level di Anthropic: perché i tuoi agenti costano troppo e come diagnosticare le cache mancate](https://www.mauriziofonte.it/blog/post/prompt-caching-workspace-level-anthropic-agenti-90-percento-risparmio.html)

  Dal febbraio 2026 Anthropic offre prompt caching workspace level con cache hit al 10 del prezzo input. Eppure nella maggioranza delle integrazioni · 18 Giugno 2026

  ![Prompt caching workspace-level di Anthropic: perché i tuoi agenti costano troppo e come diagnosticare le cache mancate](https://www.mauriziofonte.it/image/004620070-prompt-caching-workspace-level-anthropic-agenti-90-percento-risparmio.jpg)
- [Header Expires per file htaccess](https://www.mauriziofonte.it/blog/post/header-expires-htaccess.html)

  Configurare il caching del browser via .htaccess è ancora una leva di performance reale, ma la ricetta "ExpiresByType, un mese per immagini, · 1 Aprile 2026

  ![Header Expires per file htaccess](https://www.mauriziofonte.it/image/000400070-header-expires-htaccess.jpg)
- [Containerizzare Laravel con Docker: dallo sviluppo alla produzione](https://www.mauriziofonte.it/blog/post/containerizzare-laravel-docker-sviluppo-produzione.html)

  Un setup Docker per Laravel che funziona uguale in sviluppo e in produzione elimina la classe di bug che si manifestano solo sul server. Come · 11 Agosto 2026

  ![Containerizzare Laravel con Docker: dallo sviluppo alla produzione](https://www.mauriziofonte.it/image/005050070-containerizzare-laravel-docker-sviluppo-produzione.jpg)
- [Google PageSpeed insights: il metro di paragone tra un sito web “fatto bene” e uno “fatto male”](https://www.mauriziofonte.it/blog/post/perche-google-pagespeed-insights.html)

  7 Giugno 2023

  ![Google PageSpeed insights: il metro di paragone tra un sito web “fatto bene” e uno “fatto male”](https://www.mauriziofonte.it/image/000640070-perche-google-pagespeed-insights.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Breakpoint per le Media Query di Bootstrap 3", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/boostrap-3-media-query-breakpoints.html

Pubblicato: 2026-02-13 · Aggiornato: 2026-06-15.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.