Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

CSS Responsive Layouts Media Queries Creating Breakpoints

Robert Ungar
Robert Ungar
15,723 Points

So what do you actually use for breakpoints?

I sort of get what Nick is trying to say here, but I don't feel like he's answering the question. OK, sure, it's a pain to have to update your code when a new device comes out but at a certain point, you have to make a selection for a breakpoint, no?

When you're letting the content determine your breakpoints, rather than the device, that doesn't really help. You still need to insert an actual width, so what are you supposed to use then? Maybe someone can explain this better than the video.

8 Answers

Ken Alger
Ken Alger
Treehouse Teacher


Nick Pettit & Guil Hernandez are masters of CSS breakpoints and responsive design. Breakpoints can indeed be confusing, but let me attempt to explain what I believe the course content is trying to get across.

Yes, you need to put in hard numbers for breakpoints, there are common "recommended" major breakpoints available, one common approach is:

320 pixels - For small screen devices, like phones, held in portrait mode.

480 pixels - For small screen devices, like phones, held in landscape mode.

600 pixels - Smaller tablets, like the Amazon Kindle (600×800) and Barnes & Noble Nook (600×1024), held in portrait mode.

768 pixels - Ten-inch tablets like the iPad (768×1024) held in portrait mode.

1024 pixels - Tablets like the iPad (1024×768) held in landscape mode, as well as certain laptop, netbook, and desktop displays.

1200 pixels - For widescreen displays, primarily laptop and desktop browsers.

However, as you can already surmise, there are a lot more options out there in today's market. My understanding of what the course is trying to get across is that based on the content of your site, you design your breakpoints around that. If, for example, you are making a weather site. For small screens you provide information X and then build up. When your design starts to deteriorate as the screen size increases bingo, there's a breakpoint. Then adjust the content (larger font or images, no more hamburger menus, add images instead of text, etc.). When you have increased the screen size again, say from tablet to desktop, the design normally deteriorates again, so you create another breakpoint and adjust the content again.

Summing it up: it's your content and your design that defines the breakpoint, not the width of the most popular device in a particular moment in time.

Does that make any sense? If not please post back with further questions.

Happy coding,


Jon Koenig
Jon Koenig
3,089 Points

Great explanation!

When responsive first came about people were basically relying on Apple product breakpoints, so early on it was not at all uncommon to see media queries at 320px, 768px, and so on because these covered iPhone and iPad. However, after responsive started gaining traction and becoming more of the norm, people realized that content should dictate breakpoints, not devices. All this really boils down to is, when developing, test your site and add breakpoints when you see that the content/design is not working well at the particular breakpoint. Moving away from device specific breakpoints and instead using content driven breakpoints also makes your site more future proof because as more devices come out you haven't setup breakpoints that only cater to certain devices, you have setup breakpoints that are specific to your content.

Going back to testing, I understand that not everyone has access to a plethora of different devices, but in my opinion some testing is better than no testing. You can start by simply dragging the corner of your browser to resize the site slowly and see where things start to break down.

I use the fitWeird window monitor bookmarklet quite often to see screen width as the content breaks down: http://davatron5000.github.io/fitWeird/

28,736 Points

I couldn't agreed more with your answer !! I've been reading more articles about responsive designs lately and that's exactly what I 've retained.

Thank you as well for the link to the little tool, pretty useful.

Edit: An interesting article as well about responsive design which is 7 Habits of Highly Effective Media Queries (in the notes of the course)

mikes02 , fitWeird (awesome btw) only works under Firefox for me and not under Chrome.

Great tool, thanks for the link, definitely will be using this.

John Hampton
John Hampton
8,200 Points

Another option to test different devices is the great Device Mode feature in Chrome's Developer Tools. There is a 'Toggle Device Mode' icon between the magnifying class 'Inspect' icon and the Elements tab at the top left area of the Developer Tools frame. It lets you view any page in varying resolutions and also has a dropdown to simulate viewing as a ton of different specific devices, cellphones, tablets, you name it.

Here's the Google page for it: https://developer.chrome.com/devtools/docs/device-mode

Thanks for sharing fitWeird, didn't know it existed! I use Firefox and can see myself using this constantly

Amber Cookman
Amber Cookman
12,662 Points

Hi Robert,

What I use to determine my breakpoints in a site design is start with the mobile-first approach, with my browser sized as narrow as it will go. Once it looks good at that size, I make sure I have my Developer Tools open (I typically work in Chrome initially), and then re-size the page larger until I see a breakpoint happen - meaning, a point where any one of many things is happening, from the content flow seeming off, to fonts clearly being an inappropriate size, to overflows, or needing to float elements left or right.

With my Developer Tools open, it shows me in the upper-right corner of my browser window the exact pixel point at which that break has occurred, then I go into my CSS and fix the breaks in my design inside a media query. This process continues until I have taken my browser to full-screen. If you use relative-sizing (percentages, ems, rems) the whole way through your CSS, you really won't have to do much tweaking.

I prefer this method because you never know what size the newest devices will be, and this makes for much more maintainable code when reaching for the goal of being easily seen on as many devices as possible. While using a pre-set list of breakpoints certainly is an option, it can make for an odd user experience on a device that sits narrowly outside of a media query, yet has the same bug in design that is adjusted for just 10px or so up/down in width.


To quote from the Brad Frost article in the teachers notes:

"The Web is inherently fluid, so it’s our job to create interfaces that look and function beautifully on any screen instead of in just a few arbitrary buckets. -- Brad Frost"

Brad Frost also quoted Stephen Hay in the same article:

"Start with the small screen first, then expand until it looks like shit. Time for a breakpoint!" --Stephen Hay (pardon the bad word, but I didn't say or write it) :)

Robert Ungar
Robert Ungar
15,723 Points

Hey Guys,

Thank you for your thoughtful replies. I'm not trying to be obtuse, but I'm still not totally getting it. I understand what you and Nick are saying, in that you should ask, "How does my content look and where does it break down?," but aren't those essentially based on how they look on different categories of devices? What is it that determines that the content "breaks down?"

After you make the browser size a little bit bigger, what looks good on a phone-sized screen doesn't look good on a tablet. What looks good on a tablet doesn't look as good on a laptop when it's a little bigger. When it's a little bigger than that, it doesn't look as good on a desktop monitor.

So there has to be some standard to base that on, doesn't there?


You are getting too hung up on the concept of devices, try to put the devices out of your mind. Also, there is no metric for every site as far as when content breaks down, that is entirely dependent on the design and also personal preference for how you see things changing at that particular breakpoint. The goal here is to start mobile first and work your way outward and add media queries as the content/design calls for it. There is no one right way to do it, and some designs may require more breakpoints than others, that is why it is best to let content dictate it and not get stuck into any one pattern as it relates to specific devices.

Artem Syromiatnikov
Artem Syromiatnikov
4,706 Points

I find it unclear why are pixel values used to defined the break points. My phone has 4.7" screen, my desktop monitor size is 24" - and they both share the same Full HD resolution (1920x1080). Obviously I want to see different layout for these two devices, but they correspond to the same "the largest" media query. Are there different ways to define breakpoints?

Giuseppe Ardito
Giuseppe Ardito
14,130 Points


Probably the answer to your question resides in the pixel-ratio media feature. https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#-moz-device-pixel-ratio

In fact, most of the mobile devices provided with an HD display have a increased pixel density, compared to bigger screens.

As you will see from this list of device screen features iPhone 6, for example, will have a CSS width of 370px whereas the physical size is 750px.

You will be, then, able to select more precisely any kind of device.

I hope this helps.

Robert, you can add a new media query for every type of device if you wish. Just find a list somewhere on Google that shows the screen sizes for every type of device. Obviously this is going to take a very long to implement though.