Tailwind CSS & Responsive Viewport Breakpoints Markdown Table Template
A breakpoint table is the contract between a design system and the code that implements it. It lists each responsive prefix, the viewport width where it starts applying, the media query it compiles to, how wide the container utility gets, and the kind of device that usually lands in that range. Designers use it to decide which frames to draw; developers use it to know what md: will actually do before they type it.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
This version is built around Tailwind CSS’s default scale, which many teams adopt even outside Tailwind because the steps are sensible: 640, 768, 1024, 1280, and 1536 pixels. In Tailwind v4 those values are defined in rem (40rem through 96rem) as theme variables, and the framework is mobile-first: an unprefixed class applies at every width, and each prefix adds styles from its minimum width upward. Reading sm: as “on small screens” is the most common misunderstanding this table exists to prevent.
A good breakpoint table is exact about the numbers and modest about the devices. Widths, queries, and container sizes should be copied from the configuration your project actually ships. Device classes are only rough guides, since a phone turned sideways or a laptop at 150% display scaling can land a tier away from where people expect. Treat breakpoints as places where your layout needs to change, not as a list of devices.
Formatting This Table in Markdown
A tailwind css & responsive viewport breakpoints table puts a few things in cells that Markdown treats as syntax. These are the ones to watch so it renders correctly on GitHub, GitLab, Obsidian and docs sites.
Wrap at-rules and prefixes in code spans
A bare
@mediaor@containermay be treated as a user mention in GitHub issue, pull request and comment bodies. Inside a code span,>=and<also stay literal, so a query like@media (width >= 40rem)is copied exactly.Arbitrary-value classes need code spans
Tailwind classes such as
grid-cols-[1fr_2fr],min-[320px]:flexand*:p-4contain brackets, underscores and a leading asterisk that Markdown may interpret. Inside backticks they print exactly as written.Put paired queries on separate lines
For range variants like
md:max-lg:, put each query in its own code span and place<br>between the spans, not inside one, because inside a code span<br>prints as text. See line breaks in cells.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Breakpoint Prefix | left :--- | The variant prefix in a code span with its trailing colon, such as md:, exactly as it appears in class names. Include a first row for the unprefixed base styles, since in a mobile-first system that row is where most styling starts. |
| Min Width (px) | right ---: | The width in CSS pixels at which the prefix starts applying. Right-aligned so the numbers step up visibly. In Tailwind v4 the source of truth is the rem value; list pixels at the default 16 px root, and add rem in brackets if your team thinks in rem. |
| CSS Media Query | left :--- | The query the prefix compiles to, in a code span. Tailwind v4 emits the range syntax @media (width >= 48rem); older versions and hand-written CSS use @media (min-width: 768px). Both mean the same thing in current browsers. |
| Max Container Width | right ---: | The max-width the container utility takes at this breakpoint. In Tailwind it equals the breakpoint itself, and the base row is 100%. Right-aligned. Other frameworks, such as Bootstrap, use container widths smaller than their breakpoints. |
| Target Device Class | left :--- | A short, hedged description of who typically falls in the range, such as “tablets in portrait”. Keep it general; exact device widths belong in a separate device viewport reference where they can be maintained. |
How to Fill It In
- 1Read the breakpoints from your project, not the docs. In Tailwind v4 look for
--breakpoint-*variables inside your@themeblock; in v3 checktheme.screensintailwind.config.js. Anything not overridden uses the defaults. - 2Compile a test class for each prefix and inspect the generated CSS to fill the CSS Media Query column. This catches custom breakpoints, removed defaults, and any
max-widthstyle screens a teammate configured. - 3Check the container behaviour in your build: whether you centre it with
mx-auto, add padding, or have customised it with@utility container. Note any of that under the table, because v4 no longer has config options for centring or padding. - 4Assign device classes using your analytics screen-width report. Look at which widths cluster around each breakpoint and describe the bands in those terms.
- 5Resize a real page through each boundary in browser DevTools (639 → 640, 767 → 768, and so on) and confirm the layout changes where the table says it does.
Ready-to-Paste Variations
Tailwind v4 theme variables
The native v4 view: rem values as defined in the theme, and the exact query each one compiles to. Override a value in @theme to move a breakpoint.
| Variant | Theme variable | Value | Generated query |
| :--- | :--- | ---: | :--- |
| `sm:` | `--breakpoint-sm` | 40rem | `@media (width >= 40rem)` |
| `md:` | `--breakpoint-md` | 48rem | `@media (width >= 48rem)` |
| `lg:` | `--breakpoint-lg` | 64rem | `@media (width >= 64rem)` |
| `xl:` | `--breakpoint-xl` | 80rem | `@media (width >= 80rem)` |
| `2xl:` | `--breakpoint-2xl` | 96rem | `@media (width >= 96rem)` |Targeting a single range with max-* variants
Mobile-first prefixes apply upward forever. Combine them with max-* variants when a style should apply only inside one band.
| Class prefix | Applies when viewport is | Typical use |
| :--- | :--- | :--- |
| `max-sm:` | below 640px | Phone-only stacking or hidden elements |
| `sm:max-md:` | 640px up to 767px | Narrow tablet or large landscape phone tweak |
| `md:max-lg:` | 768px up to 1023px | Tablet-only two-column layout |
| `lg:` | 1024px and wider | Desktop navigation |Bootstrap 5 for comparison
Useful when migrating or documenting a mixed codebase. Note that Bootstrap’s container widths sit below each breakpoint, unlike Tailwind’s.
| Bootstrap tier | Min width (px) | Container max width (px) |
| :--- | ---: | ---: |
| `xs` (none) | 0 | 100% |
| `sm` | 576 | 540 |
| `md` | 768 | 720 |
| `lg` | 992 | 960 |
| `xl` | 1200 | 1140 |
| `xxl` | 1400 | 1320 |Common Mistakes
Using
sm:to style phones.sm:applies at 640 px and above, which no phone in portrait reaches. Write the phone styles unprefixed, then override them at larger breakpoints, or usemax-sm:for phone-only exceptions.Assuming landscape phones land in the
smtier.Many current phones are 844–956 CSS pixels wide in landscape, so they hit
md:. Test landscape explicitly instead of trusting the device column.Documenting v3 pixel values and
min-widthqueries for a v4 project.v4 defines breakpoints in rem and emits range-syntax queries. The pixel equivalents are the same at a 16 px default, but copy the real theme variables so overrides and removals show up in the table.
Adding a breakpoint for every new device launch.
Extra breakpoints multiply the states every component must handle. Add one only when a real layout breaks between two existing breakpoints, and consider a container query for component-level changes.
Related Markdown Table Templates
Browse all 50 templatesMobile Device Screen Viewports & Density
Common mobile device viewport widths, CSS logical pixels, physical resolutions, aspect ratios, and device pixel ratios (DPR).
Conventional Commits & Semantic Releases
Conventional Commit specifications mapping commit type prefixes to SemVer release impacts, changelog categories, and example formats.
GraphQL Schema Types & Query Operations
Document GraphQL Queries, Mutations, Subscription types, input parameters, return payloads, authentication requirements, and deprecations.
Tailwind CSS & Responsive Viewport Breakpoints: Frequently Asked Questions
Why does Tailwind v4 use rem instead of pixels for breakpoints?
Rem in media queries is relative to the browser’s default font size, not your CSS. If a reader raises their default from 16 px to 20 px, a 40rem breakpoint moves to 800 px, so the layout adapts to larger text instead of squeezing it.
How do I add or remove a breakpoint in Tailwind v4?
Inside @theme, define a new variable such as --breakpoint-xs: 30rem to add an xs: variant, or set an existing one to initial to remove it. Use the same unit as the other breakpoints so the variants sort in the right order.
Should I use breakpoints or container queries?
Use viewport breakpoints for page-level layout such as navigation and grid columns. Use container queries (built into Tailwind v4 with @container and variants like @md:) when a component must adapt to the space it is placed in, such as a card used in both a sidebar and a main column.
Does the container utility centre itself?
Not in Tailwind v4. container sets the width to 100% and caps the max width at each breakpoint; centring and padding are up to you with mx-auto and px-*, or by extending it with @utility container.