BrowserCaps and other Browser Testing/Detection Resources

BrowserCaps XML for ASP.Net -- accurately detect Mozilla/Firefox, Netscape, Opera, Safari, Konqueror

Page last updated: May 19 2005

background   (skip)

intro: ASP.Net -- its Request.Browser object is useful for easy browser detection.  Request.Browser uses the <browserCaps> section of the machine.config XML file (and the optional web.config XML file) to match the current browser's UA (User-Agent) string with its matching capabilities. 

problem: just like ASP's browscap.ini before it, nobody official is updating this info.  Microsoft pawns the job off on, which doesn't care about doing the world a service (it's busy selling its competing BrowserHawk product instead).  As a result, machine.config is already woefully out-of-date and unaware of newer browsers like Mozilla/Firefox, Netscape 7, Safari, and Konqueror, so it tells Request.Browser that they are "Netscape 5" (though Safari and Konqueror are wholly unrelated rendering engines).

problem 2: I went searching and searching for a newer BrowserCaps section updated by someone else.  I found some possibilites (linked below), but I didn't like that they don't identify Netscape as Gecko (extrapolating the Netscape brand's marketing version from the real Gecko engine's version).  Since Gecko is the rendering engine underneath, that's what we webdevs should care about.

problem 3: By default, Opera lies to web servers that it is Internet Explorer.  It sends a UA string like "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera x.x".

solution: I rolled my own BrowserCaps section.  I swiped a starting point (also linked below), and warmed up my RegEx chops for the rest.  Besides identifying Netscape 6+ and Mozilla/Firebird as Gecko, my update also fixes detection of Konqueror (aka KHTML) and Safari (aka AppleWebKit), and detects Opera as itself.  Finally, it (now) also corrects the EcmaScriptVersion and TagWriter properties for Opera 6+. 

files and demos

Note: I've tested it with Netscape 6 & 7, Mozilla Firebird/Firefox 0.7-1.0, Konqueror, Safari, and Opera 6-8.


For both the web.config and machine.config files, the <browserCaps> element goes inside the <system.web> element (inside <configuration>), like so:
Warning: Machine.config is already full of other important code.  Do not remove or replace any of it!  Just insert the browserCaps contents (contents only!) into the end of the existing browserCaps section.


To verify that the BrowserCaps update is working, copy my sample test page into your web application (rename it without the trailing .txt extension), and load it in whatever browser you want to test.  I also recommend comparing the results before and after you update the browserCaps section.

Compared: Web.config -vs- Machine.config

  Web.config Machine.config
Scope: Single web application. All web applications on web server.
File Location: Root of each web application.  (e.g. c:\Inetpub\wwwroot\web.config) Usually %windir%\Microsoft.NET\Framework\v(version#)\CONFIG\machine.config .
Pros: Deploys with web application (makes "xcopy-deployment" easier). Easy to apply to all web applications on an entire web server.
Cons: Must be deployed to each web application separately. • Does not deploy with web application, since it's not contained by it (so no "xcopy-deployment").
• Must have system access to that file (not likely if it's 3rd-party web host).
• More dangerous: can accidentally mess up on an entire web server.


other people's BrowserCaps updates

awesome testing tools

Multiple IE's in Windows - Joe Maddalone (whom I owe at least a beer for this) has exposed the secret of Microsoft's easy way to do this. Now there are just the other OSs and their browsers to deal with.

other browser detection resources


As-is, etc.  If you ask nicely, I may provide support via email.


-Rob (@slingfive) Eberhardt, Slingshot Solutions
Use freely, but be honest about it.  I just ask for credit, and would love to see any improvements or corrections you might make.