Real-World Browser Size Stats, Part II

This article was originally posted at

In Part I of this article I showed you how to write your own script(s) to track the screen resolution, browser viewable size, and bit-depth, of your users. While you are gathering your own statistics, I’ll offer mine up for review.

The site for which I gathered these statistics is It is the web site for my company, Algonquin Studios. It is not a portal site, or really any other kind of traditional destination on the web. It is a site that offers corporate information. Much of the site traffic comes from searches on Yahoo! and Snap for web development, enterprise application development, and various other software and web-related topics. A good deal of traffic comes from client sites, including a popular local not-for-profit. The rest of the traffic have no referrers and most likely are existing clients, leads, or people who just check on us every now and then (competitors, partners, friends, etc.).

I started with 1,000 records, and discarded 14 that had no data. There are some records that have questionable data, but only those with a bit-depth of ‘0’. So that left 986 good records on which I based these results. What I’ve done is break the data down per resolution tier. But first I will cover the aggregate data.

The window width and height represent the viewable space within the window, not the actual window size. Instead of guessing who had what tool bars open, it seemed easier to just capture the actual usable real estate. Please keep that in mind as you view these numbers.

All Users

Screen Width Screen Height Bit-Depth Window Inner Height Window Inner Width
Mean 941 705 21 806 485
Median 1,024 768 16 783 446
Mode 1,024 768 16 780 602

Highest 2,560 1,024 32 1,372 1,014
Lowest 640 480 0 80 51

Screen Resolution Stats
I’ve also created this handy chart to show you the actual numbers and percentage breakdowns of each resolution that visited the site. The x-axis represents the screen resolution, and the y-axis represents the number (of 986) and percent of users at that resolution.

640 x 480 (56 users, 5.7%)

Window Inner Width Window Inner Height Bit- Depth
Mean 600 304 17
Median 620 314 16
Mode 620 314 16

Highest 636 420 32
Lowest 416 156 1

800 x 600 (393 users, 39.9%)

Window Inner Width Window Inner Height Bit- Depth
Mean 719 397 20
Median 779 420 16
Mode 780 434 16

Highest 843 524 32
Lowest 80 96 8

832 x 624 (11 users, 1.1%)

Window Inner Width Window Inner Height Bit- Depth
Mean 756 442 21
Median 761 455 16
Mode 764 422 16

Highest 811 487 32
Lowest 669 365 8

1,024 x 768 (402 users, 40.8%)

Window Inner Width Window Inner Height Bit- Depth
Mean 881 539 22
Median 918 579 16
Mode 1,004 602 16

Highest 1,028 768 32
Lowest 80 51 8

1,152 x 870 (62 users, 6.3%)

Window Inner Width Window Inner Height Bit- Depth
Mean 925 630 25
Median 889 667 32
Mode 836 696 32

Highest 1,148 731 32
Lowest 659 364 0

1,280 x 1,024 (41 users, 4.2%)

Window Inner Width Window Inner Height Bit- Depth
Mean 963 710 22
Median 932 755 24
Mode 1,260 597 32

Highest 1,276 886 32
Lowest 708 347 0

1,600 x 1,200 (18 users, 1.8%)

Window Inner Width Window Inner Height Bit- Depth
Mean 960 755 25
Median 883 758 28
Mode 883 771 32

Highest 1,372 1,014 32
Lowest 751 480 16

Other Users

There are also a few records that had unique settings. They are as follows:

  • One user with monitor resolution of 767 x 553 x 32-bit. Viewable browser area was 763 x 442.
  • One user with monitor resolution of 960 x 720 x 16-bit. Viewable browser area was 940 x 578.
  • One user with monitor resolution of 2,560 x 1,024 x 16-bit. Viewable browser area was 628 x 623.


Some of you who are better number crunchers than I may be interested in looking at the log. Some of you may want to verify what I’ve found. You can get your own copy of the log, with IP addresses removed.

You will note some odd numbers above every now and then. Some browsers reported ‘0’ as the bit depth. This is most likely incorrect, but I have left the data in there instead of dumping the whole record. A bit-depth of ‘1’, however, is quite possible. You will also note that while bit-depths can come as 1, 4, 8, 16, 24, and 32, some charts show a mean bit-depth of 17, or some other number. This is an average. I leave it up to the user to determine whether or not he/she would round it up or down. In these cases, the median or mode would be more useful.

Some related articles


Real-World Browser Size Stats, Part I

This article was originally posted at

Everybody has their own take on what resolution their users have. Sometimes that target resolution is based on hard data, sometimes it’s a best-guess, and sometimes it’s just based on the designer’s own personal preferences.

One thing this ignores, however, is the window size of the user. Not all users at 1,024 x 768 resolution surf at full screen, so designing a page at 1,000 pixels wide would not be a good idea. Some of you may recall my article 640 x 480 Isn’t Dead Just Yet. This article offers a way to determine if that’s true for your site.

Instead of just guessing what resolution users of my company’s site have, I decided to test it for myself. In addition, I wanted to know each user’s window size and each user’s bit-depth. This article will describe my methods. In Part 2, I’ll discuss my results.

The Methodology

In order to capture the screen resolution, browser size, and bit-depth, you have to use client-side script. Unfortunately, both Internet Explorer and Netscape Navigator can report these numbers a bit differently. Internet Explorer will tell you the size of the user’s screen after it subtracts the Windows Task Bar, as well as the Microsoft Office Bar, or any other tool bars. This means a screen set to 800 x 600 could report itself to Internet Explorer as 720 x 560, depending on the tool bars and the user’s windows settings for icon and text size. Netscape Navigator will report the full 800 x 600, however.

Also of note is that the script used to gather this information works only on the 4.x+ browsers. So you immediately have skewed data in case your site is hit by a lot of 3.x and older browsers. One could reasonably assume that a 3.x user has a smaller screen resolution and lower bit-depth, but there is no way to verify that using this method. As such, keep in mind that you are still only capturing data on a sub-set of your visitors, unless you have 100% 4.x users.

Finally, keep in mind that the web is a moving target in general. The information you collect is really only valid for the time it was collected. Newer systems and browsers are always coming out, so if you are relying on this information a year from now, you may be doing yourself a dis-service.

The Client-Side Script

It is important to know that you cannot write the screen and window information to the server via JavaScript. To prevent requiring the user to submit a page, and to prevent writing all the data to the URL, I opted to set cookies with the data. Please note that I attempted to name the cookies close to plain English so users who have cookie warning enabled will know just what I am trying to write to their machine. By writing to a cookie, the next page the user visits on my site can execute server-side script to pull the values from those cookies and write that data to somewhere on the server.

To prevent capturing a user’s information over and over I coupled this script with my splash page, which already has code to prevent a user from seeing it more than once a month. You can get information on how to do that from the tutorial, Let the User Skip the Splash Page. In this case, I use the ASP (server-side) version, reducing the load on the client to manage the cookie reading and page reloading. If you do not use any method to capture and write the data once per user, then you will have to manually pull all records with duplicate IP addresses, potentially removing different people from behind one firewall. Also keep in mind that an AOL user could get recorded many times under multiple IP addresses thanks to AOL’s proxy methods. If the user does not accept cookies, then you have nothing to worry about, you just won’t get any data from that user.

Below is the script I used to capture the information. I had this script in the <body> tag, after all the content. You’ll note that I am not concerned with the browser window size, but instead with the viewable area within the window. Every user can have a different combination of browser chrome settings, tool bars, button bars, etc., taking up space. So, instead of trying to guess who has what tool bars open, I just find the viewable area.

<script language="JavaScript">
var wHeight, wWidth, sHeight, sWidth, bitDepth;

if (document.all)
	{	wHeight = document.body.clientHeight;
		wWidth = document.body.clientWidth;
		sHeight = screen.height;
		sWidth = screen.width;
		bitDepth = screen.colorDepth; }
else if (document.layers)
	{	wHeight = window.innerHeight;
		wWidth = window.innerWidth;
		sHeight = screen.height;
		sWidth = screen.width;
		bitDepth = screen.colorDepth; }

document.cookie = "wHeight=" + wHeight + ";";
document.cookie = "wWidth=" + wWidth + ";";
document.cookie = "sHeight=" + sHeight + ";";
document.cookie = "sWidth=" + sWidth + ";";
document.cookie = "bitDepth=" + bitDepth + ";";
// -->

The Server-Side Script

Since our site uses Active Server Pages, the following code is VBScript. However, it’s very basic code, so if you can read cookies, concatenate strings, and write to a file or database on the server in your server-side code, you’ll be all set.

You may wish to modify how I write the data. In the script below, I write the x-value, the letter ‘x’, and then the y-value. You’re probably better off not concatenating them, and instead, given my example, using a pipe (|) instead of an ‘x’ to create two fields instead of one. It’s hard to crunch numbers that aren’t numbers.

You’ll note I also write the date, the time, the browser, and the IP address. These fields are handy to prevent duplicates, and to see which browsers are giving you trouble with the script. I also write another cookie just to make sure I don’t log a user’s information more than once per month — in case that user gets by my splash page script.

'## Screen Resolution Logging

strBrowser = Request.ServerVariables("HTTP_USER_AGENT")
strIP = Request.ServerVariables("REMOTE_ADDR")
strNowTime = FormatDateTime(Now,vbShortTime)
strNowDate = FormatDateTime(Now,vbShortDate)

IF NOT Request.Cookies("ScreenRes") = "TRUE" AND NOT Request.Cookies("bitDepth") = "" THEN

	wHeight = Request.Cookies("wHeight")
	wWidth = Request.Cookies("wWidth")
	sHeight = Request.Cookies("sHeight")
	sWidth = Request.Cookies("sWidth")
	bitDepth = Request.Cookies("bitDepth")

	TextRecord = sWidth & "x" & sHeight & "|"
	TextRecord = TextRecord & wWidth & "x" & wHeight & "|"
	TextRecord = TextRecord & bitDepth & "-bit|"
	TextRecord = TextRecord & strNowDate & "|"
	TextRecord = TextRecord & strNowTime & "|"
	TextRecord = TextRecord & strBrowser & "|"
	TextRecord = TextRecord & strIP

	Set objFSO = CreateObject("Scripting.FileSystemObject")
	Set objNewFile = objFSO.OpenTextFile("X:/XXX/scrlog.txt", 8)

	objNewFile.WriteLine TextRecord


	'## Cookie Setting

	'## Adds 1 month onto current date
	'## so cookie will expire 1 month from now
	strNowDate = FormatDateTime(Now,vbGeneralDate)
	NewDate = DateAdd("w",1,strNowDate)

	'## This sets the cookie so that
	'## the next time the user comes back
	'## they will skip the splash page
	Response.Cookies("ScreenRes") = "TRUE"
	Response.Cookies("ScreenRes").expires = cdate(NewDate)



Once you have this in place, you can sit back and watch the data roll in. You should designate a time-frame or target date in advance. My goal was 1,000 entries, which for out site was three months. From there it’s just a matter of importing the data to a spreadsheet or database and sifting through the data to find the numbers.


This article has shown you a method to write your own screen resolution, browser size, and bit-depth tracking. Part 2 will show you the results from my site,