Grow your CSS skills. Land your dream job.

Screen Resolution ≠ Browser Window

Published by Chris Coyier

When I tweeted this and then followed up with this, I got comments like this. That comment has a perfectly valid point.

We often talk about screen resolution, which is not the relevant statistic when thinking about what space our website's visitors have available. The relevant statistic is browser window size. So why do we talk about screen resolution so much? Well probably because in the most popular analytics software in the world, Google Analytics, it's the only data you get.

(The Google Analytics team is aware of this)

And so, what are we to do? Well, start measuring browser size, for one.

But first, a word.

What if we figured out all kinds of data about our visitors browser sizes. What is to be done with this data once we have it? If @beep has taught us anything, it's that we can and should accomodate to browsers of any shape and size.

But still, having information is never a bad thing. Smarter men and women than me may see things I do not and think of reasonable actions to take based on this data.

Getting the Data

Since Google Analytics can't currently help us, we'll need to run some JavaScript on the page ourselves to get the data. jQuery makes it easy to measure sizes as well as make and Ajax call to POST the data to a script that can save it:

$.ajax({
  type: "POST",
  url: "/savedata.php",
  data: {
    width        : $(window).width(),
    height       : $(window).height(),
    screen_width : screen.width,
    screen_height: screen.height
  }
});

Now we just need that script savedata.php to be ready to accept and save that data. First we need a database, so here's a simple structure for one:

I'm no MYSQL expert, but this is what exporting the structure from phpMyAdmin gave me:

CREATE TABLE `data` (
  `id` int(11) NOT NULL auto_increment,
  `width` int(11) NOT NULL,
  `height` int(11) NOT NULL,
  `screen_width` int(11) NOT NULL,
  `screen_height` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=72141 DEFAULT CHARSET=utf8 AUTO_INCREMENT=72141 ;

And now my wicked primitive script for saving the POSTs:

<?php

	$dbhost = 'localhost';
	$dbuser = 'db_user_name';
	$dbpass = 'db_password';
	
	$conn = mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql');
	
	$dbname = 'db_name';
	mysql_select_db($dbname);
		
	$width         = mysql_real_escape_string($_POST['width']);
	$height        = mysql_real_escape_string($_POST['height']);
	$screen_width  = mysql_real_escape_string($_POST['screen_width']);
	$screen_height = mysql_real_escape_string($_POST['screen_height']);
	
	$sql = "INSERT INTO data ( width,  height,  screen_width,  screen_height)
	      VALUES           ($width, $height, $screen_width, $screen_height)";
	
	if (!mysql_query($sql, $conn)) {
		die("Error:" . mysql_error());
	}
	
	echo "1 Record Added";
		
	mysql_close($conn);

?>

That's what I did on CSS-Tricks for one day. If you'd like, here's the complete data I collected as SQL.

Looking At The Results

Remember: ALL of this data was collected from css-tricks.com. So it's a bunch of designer nerds, probably. It's only relevant to this site and sites with very similar audiences.

First, the borin' ol screen resolution data. I got this by querying 500 random samples of data and laying div's of that size on top of each other with as light of gray as I could make. Incidently, its rgba(0,0,0,0.004), because rgba(0,0,0,0.003) is pure white (weird).

Notice the rather hard lines. Monitors only come in so many sizes. Makes sense. Here's what happens when we do the same thing with browser window sizes though:

Much more blurry. Also makes sense. Even as I write this my browser is at some very arbitrary sizing, probably about 80% of my screen resolution. Click those images above to see them bigger. You'll notice that whatever visible hard edges there are in the browser size version, they are exactly 20px narrower than the screen size counterpart. Interesting.

If I tint the screen sizes red and the browser sizes green and put them on top of each other, this is what we get:

Notice on the outside edges the tint stays red. Not a lot of people who have extremely wide monitors have their browser window open that wide. I know I don't. Let's look at the stats for "full screen" browsers. How many people browser full screen, or with their browser window "maximized" so to speak. Well if you query only for entries where the window and the screen resolution are exactly the same, very few, less than 1%, but it get's interesting:

Totally full screen 0.85%
Within 50px of full screen 1.06%
Within 100px of full screen 9.67%
Within 200px of full screen 61.18%

So very few people browse full screen, but the majority of people browse pretty close to full screen. As speculation, it's likely the Windows folks are the ones browsing full screen, as that's much more natural behavior on that operating system. But now "full screen" is a big deal in OS X Lion, maybe that will start effecting this stuff.

If we put this stuff to a spread and use the entire data set, here's one way to break it down:

Width Range Browser Window Screen Resolution
0px - 500px 1.13% 1.02%
501px - 800px 2.01% 1.06%
801px - 1000px 2.84% 0.07%
1001px - 1200px 14.91% 6.86%
1201px - 1400px 40.65% 35.57%
1401px - 1600px 17.38% 17.17%
1601px - 2000px 20.41% 34.34%
2000px+ 0.66% 3.91%

So where is mobile in all this? Despite reports of massive growth in mobile browsing, which I do not doubt, CSS Tricks has very little mobile traffic.

Let's wrap it up with some quick hits:

  • The most popular screen resolution is 1680 x 1050 with almost 13% of visits having a monitor of that size.
  • Predictably, there is no one browser window size that is far above all others, but leading the pack is 1349 x 667 at 0.75% of visits.
  • The most popular screen resolution ratio is 16:10 with 46% of visits having that. Maybe because a lot of video is 16:9 and monitor makers wanted people to watch that but still have room for some OS chrome? 16:9 is next with 29%, 5:4 with 12%, and 4:3 with 8%.
  • All of those ratios are wider than tall. Turns out only 2% of visitors have screens that are taller than wide (or at least that report that way).
  • Actual browser windows also tend to be wider than tall, with only 3% of visits having dimensions that are taller than wide.
  • Average number of pixels per screen = 1,539,515
  • Average screen resolution = 1526 x 967
  • Average browser window size = 1366 x 784

Huge Thanks

To Jamie Bicknell of Rentedsmile Web Design for helping me wrassle together the MYSQL queries and PHP needed to do anything useful with the data.

Comments

  1. Thanks for the tip; was looking for something like this. One question: Does this measure the actual browser size or the available real estate one has to render within the browser? For example, does the height attribute also include any menu bars that a user may have enabled, the File menu, etc.? Is there a way to determine the actual real estate available within the browser rendering space vs. the full window if the answer is yes, it include those menus?

    • Johnathan
      Permalink to comment#

      That’s an interesting question! I don’t think javascript width/height includes any part of the browser, only content area. That means that the browser is only truly the monitor size when in full screen mode!

    • Peter
      Permalink to comment#

      The JavaScript/jQuery routine measures the *viewport* dimensions. That is, the actual available real estate excluding any toolbars, scroll bars, window chrome, etc.

      This is also why the “hard edges” for the viewport width are exactly 20px narrower than the hard edges for the screen width; this is the width of the scroll bar on Windows. (A maximized window only has a scroll bar, it doesn’t show it’s edges anymore.)

      If the measurement had been done for pages that don’t have a scroll bar (because everything is “above the fold”), then the maximized viewport width would be exactly the same as the screen width.

  2. I don’t understand why you would go to the trouble of making a table/script to record this information when you could just as easily write it out to a custom analytics variable? o_O

    • Tommy
      Permalink to comment#

      So do you have one to share with the community? I’d love to install it in my GA. I figure if it’s easy you’ve already knocked it out (or can knock it out right quick). :)

    • Cuz I don’t know how to do that. But that does sound easier/better. If you wanna adapt this and blog about it, that’d be rad.

    • Gathering Analytics data isn’t the most easy thing in the world and since Chris asked for a specific set of data, this isn’t all that bad, considering. I for one know the struggles as a developer, using the Analytics data and believe me, it’s much easier to disregard it if you’re not using it on a large scale like I do with my CMS.

    • Chilla42o
      Permalink to comment#

      You can collect the data using GA event tracking, like:

      var bw, bh; //browser width, height
      if (document.body && document.body.offsetWidth) {
       bw = document.body.offsetWidth;
       bh = document.body.offsetHeight;
      }
      if (document.compatMode=='CSS1Compat' &&
          document.documentElement &&
          document.documentElement.offsetWidth ) {
       bw = document.documentElement.offsetWidth;
       bh = document.documentElement.offsetHeight;
      }
      if (window.innerWidth && window.innerHeight) {
        bw = window.innerWidth;
        bh = window.innerHeight;
      }
      
      var _gaq = _gaq || [];
      _gaq.push(['_setAccount', 'UA-XXXXXX']);
      _gaq.push(['_trackPageview']);
      
      //track current browser window size
      _gaq.push(['_trackEvent', 'browser size', bw+'x'+bh]);
      //you may also track width and height separately which gives you more options for custom reports:
      _gaq.push(['_trackEvent', 'browser width', bw]);
      _gaq.push(['_trackEvent', 'browser height', bh]);
      
      (function() {
        var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
        ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
        var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
      })();
    • Alternatively, you can use Liquid Fold to get exactly these stats and not worry about the Javascript/server side of things.

    • Peter
      Permalink to comment#

      Here is the code I use. It only measures the viewport width, and rounds it off to multiples of 100 pixels:

      // window width (user-defined parameter)
      var WindowWidth = 0;
      if( typeof( window.innerWidth ) == ‘number’ ) {
      //Non-IE
      WindowWidth = window.innerWidth;
      } else if( document.documentElement && ( document.documentElement.clientWidth) ) {
      //IE 6+ in ‘standards compliant mode’
      WindowWidth = document.documentElement.clientWidth;
      } else if( document.body && ( document.body.clientWidth) ) {
      //IE 4 compatible
      WindowWidth = document.body.clientWidth;
      }
      pageTracker._setVar(Math.round(WindowWidth/100)*100);

      (Note: I’m still using the old GA syntax. I know.)

  3. is this maybe a good use of google analytics custom variables to tie it all together?

  4. Scott
    Permalink to comment#

    Aren’t you forgetting browser chrome in your results? The toolbars and stuff can take up 100px or more from the height. I looked at your data and over 68% had a browser width within 50px of their screen width.

    Even that is surprising to me, since I thought that 90% of people browsed with a maximised window.

  5. You might be able to use the “user defined variables” in google analytics to track this as well. It would allow you to at least log the data within google analtyics.

  6. As Chris mentioned, browsing Fullscreen is more native behaviour to the Windows folks, like me when using my workstation, but when on Mac or Linux, using a windowed browser gives the feeling you’re reading a book or newspaper. At least, that’s how I figure my subconscious feels about it ;)

  7. This is awesome. Great analysis of your website.
    How clever damn. I believe things like this are the ones that are going to make web experience better day by day.

    Hope to give it a try when I settle my web for complete. Thanks for sharing this creations =)

  8. DED
    Permalink to comment#

    This is a good article, however, I was mistakenly thinking most developers already knew this. Screen resolution is less important today than it was because now even smaller screens have high resolution. Not that long ago the relationship between screen size (in inches) and screen resolution was tighter and thus a good statistic to look at. For one thing the same size in pixels looks different on different resolutions : if your screen is 600px wide then 80px takes up a greater percentage, and each pixel is actually larger, than if your screen is 1200 pixels wide ( screen size by resolution not inches across) . It’s a great idea to develop the means to measure both.
    DED

  9. Cool! That is some hot data.

  10. This is a very helpful writeup. thank you.

  11. It would be interesting to see how these numbers compare with the numbers for other websites. The visitors here, being mostly programmers and designers, are more likely to have very large monitors and wouldn’t use maximized mode as many sites look pretty bad if your window is over 1600px wide.

    I use maximized windows on my laptop (1366x738px) but have to resize the browser to about 60-70% of the screen width on my desktop which has 1920x1080px resolution. Effectively, I’m using almost the same browser width, no matter what screen I’m browsing on.

    • comparison to bioenergy/reiki/alternative… site – the thinking being most users will be different … the rest of important variables – almost exclusive pc/win visitors, top browsers ie and ff with even chrome far behind

      resolutions:

      1. 1280×1024 18.85%
      2. 1024×768 17.18%
      3. 1280×800 15.87%
      4. 1366×768 11.10%
      5. 1680×1050 8.11%
      6. 1920×1080 5.73%
      7. 1440×900 5.01%
      8. 1152×864 4.65%
      9. 1600×900 3.10%
      10. 1024×600 1.31%

      numbers gathered by GA , no browser size yet collected

      to the rest: plz join in with some data…

    • http://liquidfold.net/stats has a bunch of “global” stats available at http://liquidfold.net/stats and make it easy to setup and track your own stats.

      And you are correct. There is a strong correlation between larger screen resolutions and not having the browser maximized. Which also probably means the screen resolution is going to be less and less relevant as sreen resolutions tends to climb.

    • Peter
      Permalink to comment#

      These are our numbers on viewport width, rounded off to the nearest 100. Our site is for a government branch which supports social housing especially for minorities, in Norway. We have lots of visitors with little computer knowledge.

      1300: 32%
      1000: 20%
      1400: 14%
      1700: 5.8%
      1200: 5.6%
      1100: 5.1%
      1900: 4.8%
      800: 3.8%
      1600: 3.4%
      900: 1.5%

      Our site in not (yet) optimized for mobile, so most mobile browsers report a viewport width of around 800px.

      The numbers for screen resolution:
      (not set): 50% (why is this so high???)
      1280×800: 7.8%
      1280×1024: 6.6%
      1366×768: 6.3%
      1024×768: 5.6%
      1680×1050: 4.1%
      1440×900: 2.8%
      1920×1200: 1.7%
      1600×900: 1.2%

  12. Jukka
    Permalink to comment#

    Commenting on:
    > You’ll notice that whatever visible hard edges there are in the browser size version, they are exactly 20px narrower than the screen size counterpart. Interesting.

    if I understood that correctly, could this 20px difference be due to browser window borders+scroll bar taking up 20 pixels?

    • Peter
      Permalink to comment#

      Only the scroll bar. The window borders are gone when the window is maximized.

  13. does show how inane this whole ‘responsive’ design is, particularly with the concepts banded of removing artifacts, or in some cases even content based on the size of the window.

    So what, if I use Safari with its annoying non-full screen default I get penalised?

    It’s flawed, I got a 1080p TV, but if I stick my mac into it via VGA it doesn’t suddenly become 1080p does it? Nope.

    Screen resolutions are totally irrelevant almost as much as ‘the fold’ they’re the two things I wish some jerk didn’t write about on a terrible site like eConsultancy 10yrs because we’ve had to put up with the nonsense for the last decade.

  14. You mentioned that you don’t get a lot of mobile traffic (which I’m sure you get considerably less than desktop because most of us aren’t trying to learn CSS on the go—rather, when we’re able to try it out). Something to note, though, is that smart phone browsers don’t report their browser resolutions in the same way that you’d expect with a 1:1 ratio of real pixels. Mobile Safari, for example, displays all web content at a default of 980px and not 320px or 640px (SD or Retina, respectively.)

    • Peter
      Permalink to comment#

      This is from the top of my head, so I may be totally wrong.

      Mobile browsers report a bigger viewport size for non-mobile-optimized websites, because they display the whole page in a thumbnail view. That way, they work with a virtual viewport which is bigger than the physical screen. As a result, you get number for screen size which are actually smaller than the viewport size…

  15. Nate Cavanaugh
    Permalink to comment#

    One other option that is a bit more efficient as it wouldn’t require an entire library or an Ajax request is to just dynamically prepend a 0x0 image that has a src pointing to your php file that includes the dimensions of the browser window as part of the query string.
    That’s how email spammers do tracking anyway ;)

  16. well if you look at the pictures of screen/browser sizes you can see, that width lines in both cases are very sharp – its the height part that gets blured – my guess is that this is becaufe of different browser and os toolbar heights

    –also a part to mention is if you’re working from screen resolutions only, always keep some width ‘on the side’ for scrollbar and maybe older browsers with borders

    still browser size compared to screen size its one of this things that u need to know – very nice and usefull article :)

    • sry for double posting but i dont like long posts with different subject on hand …

      –more on topic: in my opinion you can expect horizontal sidebar, when working in windowed mode … this scales since bigger screens are comming in use and you have to adapt your site for smalle screens as well – so windowed mode on higher resolutions won’t be a problem …

      this only goes to a point where u don’t expect a lot of smart phone etc traffic – responsive design comes in handy for that one

  17. Chris

    These are some great points. But what we’re not taking into account is how people work with a website. Lets say from all of this you take that most people browse at a real, browser resolution of 1201px – 1400px.

    Does that then therefore mean we should design websites for this resolution? Absolutely not.

    Why? Because of how people work with your site when they load it up in non-fullscreen mode. If the website is too big, your natural reaction is to then increase your browser window size. Or vice versa. From my own observations, people like to adjust their browser window so the website is “full width”.

    No amount of analytical data will actually tell us what people are doing to their browser when they load up a website. Non-fullscreen windows are completely user expandable, they’re fluid, they can be any shape or size you want.

    As long as a website doesn’t completely screw up when re-sized, there isn’t an issue, surely? People will resize their browser, almost automatically, to suit the website they’re browsing. So this whole debacle is a bit of a sisyphean task.

    • speaking for central europe/windows&linux – in my experience people browse full screen (about 90% for shure)

    • Permalink to comment#

      It is tough to take into account whether or not people are resizing once they arrive at a site. My completely non-scientific guess is that most people don’t do this. Even folks who browse non-maximized tend to keep their window at an “optimized” size for the browsing they do, and don’t resize if they can help it.

    • Permalink to comment#

      I suspect Norm is right. I usually load Chrome up in the morning, windowed, and pretty much just leave it at the same size all day. The only time I change it is if a site for some reason doesn’t fit within the width I have the browser at, although this is pretty rare.

  18. Also, may I add to my point that people will resize the browser to suit your website. Unless I’m much mistaken, that makes your data potentially completely irrelevant, as I assume it measures the browser size then the user loads the website. However, it would surely be AFTER they load the site, that they will then resize their window to suit your website. Which you won’t have measured, so your data could possibly be not a true reflection of the actual browser window sizes people are using. Even taking into account them keeping the resized state and browsing a further number of pages.

    • Permalink to comment#

      I really don’t think this makes the data irrelevant.

      It is possible that people resize their browser after arriving at the site. However, if they are doing so, it’s most likely because the original browser size was not suited for the site. Having to resize the window is most likely an annoyance for that person. They would have preferred to keep browsing at the size they had when they arrived.

      Surely then, the ORIGINAL browser size is the more important statistic. Chris already knows the dimensions his site is optimized for. The information he’s seeking is what people would PREFER the site be optimized for.

  19. Never realized full hd users might not view sites full screen (unlike me). We’ve got a discussion going on to rebuild the entire lay out liquid or not. This measurement script might give the right answer! Thanx a lot!

  20. Ryan
    Permalink to comment#

    Nice post on something a lot of people misinterpret (including me).

    This is a super novice question, but how did Chris export his SQL data like that?

  21. Nice article. Are the statistics measured upon the first load of the page or do you look at their whole session?

    I can image visitors with small browsers adjusting their screensize AFTER they already passed their data loading the first page.

  22. Awesome Man! I liked thsi comment page design.
    And about screen resolutions, its best..

  23. Timothy McClanahan
    Permalink to comment#

    Also keep in mind that in the Windows world, there is a difference between “maximized” and “fullscreen”. Maximized is what you’re probably referring to here, at least with Windows users.

  24. Interesting idea, but at what point do we get too much data to be able to act on it? We can’t take into account every possible scenario or we would never get anything done. I suppose finding common patterns in browser size could be useful though.

  25. hey, i liked the part about the gray rgb…but i think you might be wrong about the ‘white’ one step down. i’ve got both of them up right now and can see the difference.

    you other guys glazed me over.

  26. Permalink to comment#

    I’ve recently been developing the UI for a browser-based application. It is for internal use only, so my user group is set to the company employees that use it.

    I wanted to gather some usage statistics on the most common screen resolution used in our company. Well, there was nothing in the app as far as analytics goes, so I had no data to retrieve.

    Instead, I just did some soft-science and watched what people were doing, and walked around the office noting the screen resolution of a sample of users, and how they interacted with this browser based app.

    Come to find out, I could go wider than the “safe” 960px and still be safe with my user base. But what I also found out was that if someone didn’t have their browser maximized and the right side of the app was cut off, they simply just maximize their browser or drag the corner until the app fits.

    So as I read this article, I am finding myself thinking “this is a great min/max experiment, but how this effects actual usage is largely a small consideration.”

    Many websites are abandoning the “above the fold” doctrine. People have been scrolling vertically online for almost 2 decades now, it’s as ubiquitous as 7 digit phone numbers (as opposed to 50 years ago when they were 5 or less).

    The point being: every browser comes with a maximize button, and people know how to use it. Trying to determine the viewport size for every case, and edge-case, is an academic endeavor. If you have time to optimize your site for every possible viewport and resolution, you clearly don’t have enough paying work to keep you busy.

    Again – it’s great to study edge-cases and try to incorporate them, but for day to day application, I’d say to make the cutoff at 2 standard deviations, maybe even 1.5.

    I’d love to know the mean and modal viewport sizes, but that’s not going to hold up development if I don’t. For now, it’s a little bit of data and a bunch of common sense.

  27. Timo

    Hi guys,

    something similar by google: http://browsersize.googlelabs.com/

    Check it out!

    Bye
    Timo

  28. Thank you… i was wonder for some time how to do that! Thank you for sharing with us!

  29. Permalink to comment#

    Hey Chris,

    I had been searching around for the same and din get hold of the exact difference between the two. Even posted a question : http://stackoverflow.com/questions/19724215/are-browser-width-and-screen-resolution-the-same . Awesome work man. Just saved me lot of head-ache trying to figure out the same.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".