Skip to page content or Skip to Accesskey List.


Main Page Content

Real World Browser Size Stats Part I

Rated 4.18 (Ratings: 9)

Want more?

  • More articles in Code
Picture of aardvark

Adrian Roselli

Member info

User since: 14 Dec 1998

Articles written: 85

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. Netscape Navigator 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 Netscape Navigator as 720 x 560, depending on the tool bars and the user's windows settings for icon and text size. Internet Explorer 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)


NOT Request.Cookies("ScreenRes") = "TRUE"


NOT Request.Cookies("bitDepth") = ""


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 our 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,

A founder of, Adrian Roselli (aardvark) is the Senior Usability Engineer at Algonquin Studios, located in Buffalo, New York.

Adrian has years of experience in graphic design, web design and multimedia design, as well as extensive experience in internet commerce and interface design and usability. He has been developing for the World Wide Web since its inception, and working the design field since 1993. Adrian is a founding member, board member, and writer to In addition, Adrian sits on the Digital Media Advisory Committee for a local SUNY college and a local private college, as well as the board for a local charter school.

You can see his brand-spanking-new blog at as well as his new web site to promote his writing and speaking at

Adrian authored the usability case study for in Usability: The Site Speaks for Itself, published by glasshaus. He has written three chapters for the book Professional Web Graphics for Non Designers, also published by glasshaus. Adrian also managed to get a couple chapters written (and published) for The Web Professional's Handbook before glasshaus went under. They were really quite good. You should have bought more of the books.

The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.