The Mobile Opera website
Opera for Symbian OS

Mobile Opera user-agent strings

This page is a brief update to the original Opera browser user agent string information in the reference section of this website and includes new user agent strings taken from current Symbian devices.

Note that the user-agent strings shown on this page do not word-wrap, which may cause side-scrolling in some browsers.

The current Symbian Opera user agent

Prior to version 6.1, the user-agent string for the Opera browser on Symbian OS has altered format with almost every release. The current format, which it's hoped will remain more or less the same in future releases, is as follows:

Mozilla/4.1 (compatible; MSIE 5.0; PLATFORM; DEVICE;BUILD) OPERA VERSION  [LANGUAGE]

An example of what you can expect a real UA string to look like is:

Mozilla/4.1 (compatible; MSIE 5.0; Symbian OS; Nokia 3650;424) Opera 6.10  [en]

Note the double space between the Opera version and Language strings, and the omission of a space separating the Device string and Build number.

Although Opera for Symbian can change its user agent string just like desktop versions it will be fairly uncommon to see it identifying as anything other than the default (spoofing as IE5). This is because current versions hide the user agent options from the browser preferences so the only way to change strings is to edit a configuration file manually. While some users will do this to identify Opera as itself (or Mozilla) the vast majority will not even be aware of it.

User-agent components

Platform

Although some older versions of Opera on Symbian OS use 'EPOC' as the platform string (That was the original name for the Symbian operating system) you can expect future versions to continue using 'Symbian OS'.

Device

The device string lets you know precisely which model of phone or PDA Opera is running on and has been included since version 6.1. You can expect this string to vary greatly as the range of Symbian handsets and localised variants grows over time. Knowing the device can be helpful when needing to determine the screen resolution or whether a particular hardware or operating system feature is implemented.

Although the number of individual devices may be large most of them will be based on one of a small group of common Symbian implementations such as Series 60, Series 90, Crystal or UIQ:

  • Series 60 devices, such as the Nokia 6600, n-Gage, Siemens SX1 or Sendo X typically have a 176x208px 12bit or 16bit colour screen. Since Series 60 devices don't include a touchscreen the keypad is used to operate the browser.
  • Crystal devices, such as the Nokia 9210i, have a 640x200px 12bit colour screen. Although these devices don't have a touchscreen they do have a virtual cursor that allows the 8-way arrow key to similate a mouse. They also include a 53-key qwerty keyboard which allows most of Opera's standard keyboard navigation to be used. Note that activating a link via keyboard navigation (A to cycle through links, then Enter to activate) will not generate an onclick event, it will just make Opera load the value of the link's href attribute.
  • Series 90 devices, such as the Nokia 7700 will typically have a 640x320px (or taller) 16bit colour touchscreen for pen-driven navigation and operation.
  • UIQ devices such as the SonyEricsson P800, P900, BenQ P30 and Motorola A920/A925 typically have a 208x320px 12bit or 16bit colour touchscreen for pen-driven navigation and operation. The way UIQ is implemented on current devices means that Opera cannot function in landscape mode though no doubt this will change when future models allow it. Existing UIQ applications that offer a landscape view must add their own code to achieve this, something Opera do not seem prepared to do (the app is already big enough!).
Build

The build refers to the build number of Opera (as opposed to the operating system or device ROM). This is not particularly useful other than to help workaround bugs/quirks specific to a particular release of Opera.

Opera version

When spoofing as another browser Opera will always append this string to the end of the user agent string so that more 'intelligent' browser sniffers can still determine that it's really Opera and work out which version is being used.

Language

Though this is most commonly English (en), Opera for Symbian is available in various languages depending on which version was installed (A single Symbian installer file often contains multiple languages, one of which is selected automatically at the time of installation) or, if included in the device ROM, what region the phone was bought in. As well as other language codes (it, fi, de, etc) you may also see regional variations of a language such as American-English (en-US).

Proprietary HTTP Headers

In addition to the standard user-agent string, releases after 6.10 for Series 60 will introduce a new proprietary field in Opera's HTTP requests. This field will provide further information about the hardware characteristics and user preferences of the device Opera is running on. The contents of the field is a semicolon-separated list of values which can be easily parsed by a server-side process (such as a CGI script, Coldfusion or PHP) when generating dynamic pages.

An example of the new request header field format is as follows:

X-OS-Prefs: fw:176; fh:208; cd:16c; pl:3; pj:1; pa:1;
fw:176
The fw value corresponds to the overall screen width of the device. Commonly seen values will be 176, 209 and 240, though expect to see larger values as mobile devices with wider screens appear over the coming months.
fh:208
The fh value corresponds to the overall screen height of the device. Common values will be 208, 220 and 240 though some mobile devices with screens as tall as 320 and 480 will eventually run Opera 7.
cd:16c
This value contains two pieces of information about the screen on the device: Screen type and colour depth. For the example value 16c, the '16' indicates it's a 16-bit display (65K colours) and 'c' means it's a colour screen (as opposed to monochrome or shades of grey). 12c would indicate it's a 12-bit colour screen (4096 colours).
pl:3
Image mode (not verified)
pj:1
This value indicates whether Javascript is enabled and will be 1 if enabled or 0 if disabled.
pa:1
CSS mode (not verified)

Note that as this field is proprietary it will not appear in the HTTP request headers of other web browsers, mobile or otherwise.

Other mobile user agents

Other variations of the Opera user agent string on Symbian devices include:

Non-Opera strings

Here are a few example user agent strings from HTML browsers which are not Opera but are also used on Symbian OS:

Browser User agent string
Netfront 
Mozilla/4.0 (SmartPhone; Symbian OS/0.9.1) NetFront/3.0
Anygraaf Doris 
Doris/1.86 [en] (Symbian)
Reqwireless Webviewer 
ReqwirelessWeb/2.0.0 MIDP-1.0 CLDC-1.0 Nokia3650
Reqwireless (spoofing as IE6) 
Mozilla/4.0 (compatible; MSIE 6.0; Nokia7650) ReqwirelessWeb/2.0.0.0

Non-Symbian strings

Purely for reference, here are the user agent strings from a Microsoft PocketPC device and a Microsoft smartphone:

Browser sniffing

Before implementing browser sniffing based upon these user agent strings, please consider the following:

Opera for Symbian OS (and other embedded platforms) is an incredibly well featured mobile web browser with the same level of support for HTML, CSS and Javascript as its desktop counterparts. On top of this Opera have developed their own Small Screen Rendering™ technology to help real-world pages adapt to handheld devices without the need for a remote proxy server to parse and simplify the content and formatting, or web authors to create and maintain a second set of pages for phones/PDAs. With Opera you really can have DHTML menus and rollover image effects running on a phone.

With all that potential at your disposal do you really want to send Opera users nothing more than a plain-text version of your site?

A stylesheet may be all you need to tailor existing pages to the screens of Symbian handsets without having to worry whether SSR™ will 'break' them. Opera 6 (and above) for Symbian OS includes support for the CSS handheld media type so by including an extra stylesheet through a @media or @import rule, or by using a second <link> tag with a media="handheld" attribute in your documents, you can retain more control over the appearance of your pages.

A stylesheet for handhelds doesn't have to be very long or complicated. You may settle for some simple formatting such as colours, fonts and borders (as well as hiding unnecessary elements by using display:none) or you may wish to invest a little more effort and use fixed/absolute positioning. This, combined with a little Javascript, can really impress your mobile visitors who will probably assume they're browsing a dedicated mobile version of your website. Because Opera also supports the :before and :after pseudo classes you can insert styled text strings into the page that should only be seen by mobile users without having to edit any of your HTML or use server-side processes.

The ideal approach for the creation of modern websites is to use simple, well structured markup along with a table-less CSS layout. Despite various urban myths about CSS, modern browsers do have adequate support to make CSS layouts practical so long as you don't share the mindset that every browser must render the page identically (does an IE5 user know or care whether an Apple Safari user is seeing something different from them or an Opera user?). Since the appearance of such pages is controlled entirely by an external stylesheet you can make major site-wide changes to desktop rendering just by altering one CSS file. Additionally you can create alternative stylesheets for visually impaired users, older browsers, printers and, of course, handheld devices. As with most technologies implemented in web browsers, how well you fare with CSS depends on your knowledge and experience with it as well as your familiarity with the various workarounds for important bugs and quirks found across common browsers. Luckily CSS is versatile enough for people to find solutions to most problems without affecting the wrong browsers.

Note that the Motorola A920 ships with a special edition of Opera 6 for UIQ that doesn't include Opera's small screen rendering technology. Motorolla and the UK's 3 network do not intend for these devices to be used on the 'real' WWW where they'll need it!

Small screen Javascript

When using Javascript intended to be interpreted by all browsers, traditional browser sniffing really isn't recommended. At a time when there are so many new web browsers appearing (on desktops, handhelds, home entertainment devices, cars, etc), many of which use browser spoofing to countermeasure browser sniffing, it's very easy for a visitor to end up with code their browser can't handle very well. Admittedly, if a browser sends out an exact copy of the MSIE 5.0 user agent string then you can't expect an author to know (server-side) what it really is and what it supports, however years of poor browser sniffing scripts has led to this becoming common practice amongst alternative and specialist browsers.

Note that even when Opera spoofs as MSIE, it always appends the word 'Opera' along with the version number to the user agent string. Also note that some firewalls and proxies change the user agent string of any desktop browser going through them so you may even find requests for files seemingly from Mozilla 3 which are really from IE6.

A better approach when using client-side scripting is object sniffing (also called object detection). Instead of trying to determine what browser/version the user has and then using your own familiarity with that browser to decide what it's capable of doing, check whether the methods, objects and properties your script will require actually exist on the device itself and code that script to act accordingly. It shouldn't matter what browser they have as long as you can either detect everything your script needs to run or create them if they don't (and then dispose of all those unnecessary if(ie)...else if(ns)... statements throughout your scripts). Then you can worry less about future browsers and unexpected user-agent strings.

If you are going to send Javascript to Opera on a handheld remember it's sensible to avoid relying on it wherever possible. Most current devices still ship with limited RAM so many users will have Javascript disabled in order to save memory. A useful technique when combining Javascript and CSS is to put any CSS that will cause problems or affect accessibility while Javascript is disabled (such as positioning and visibility properties used to create layers) into a separate file. Use the Javascript document.write() function to write a new <link> tag or @import rule in the document head and include the additional CSS safely. Unfortunately Opera 6 for Symbian cannot switch stylesheets or modify/append CSS rules via Javascript once the page has loaded. This is chiefly because Opera 6 is not based on a dynamic rendering engine and doesn't support document.styleSheets (there wasn't much use for this object or better DOM support without a dynamic layout engine to make use of them!).

Also, have forethought when using Javascript events. It's not very likely that people with touchscreen devices will drag the pen around to trigger mouseover and mouseout events as and when you expect them to. They're more likely to just tap on things which will result in a mouseover event and an onclick event occuring simultaneously. No mouseout event will occur unless the user drags the pen away from the target without lifting the pen, but they're more likely to just take the pen off the screen after tapping.

Testing for small-screens on a desktop

To help authors check how their pages display on handheld devices, Opera 7 for desktops includes a small-screen simulator that reformats pages using the same Small Screen Rendering™ technology found in Opera on PDAs and smartphones.

Use Shift+F11 in Opera 7 on Windows to toggle between normal mode and small-screen mode.

Screenshot of Opera in small-screen mode

While this is a useful tool to help ensure your pages render well, varying screen widths, system fonts and form widgets mean the simulator can only provide a close approximation of what real devices running Opera 6 will actually display. Do not consider it to be a pixel-perfect representation of all devices, especially when testing DHTML effects. These may work well in the simulator (which uses the Opera 7 dynamic rendering engine) but not on real Symbian devices still using the less capable Opera v5 & v6 static engine.

The default width of the simulator is 240px, none of which is lost to scroll bars since they appear on the opposite side of the screen (as shown in the screenshot). Very few devices share this display width however. In fact, only Linux PDAs like the Sharp Zaurus have a 240px wide screen and 16px of that is used by the scroll bar. The majority of Symbian handsets have a display just 176px across (75% of the simulator) while others such as the SonyEricsson P800/P900 have a screen width of 208px. In the likely event that a scrollbar is displayed, the content area will be reduced to 196px.

Although some forthcoming Symbian devices will have larger screens than this none will be exactly 240px wide. Those with VGA-width screens may also include a variation of Opera's SSR designed for medium-sized displays.

Opera 8 for Symbian OS

Just a quick update to include an example Opera 8 user agent string for Series 60 devices. The format remains pretty much the same as the later version 6 UA strings so expect to see different devices and manufacturers in the Device segment of the string.

Mozilla/4.0 (compatible; MSIE 6.0; Symbian OS; Nokia 6600/4.09.1; 6329) Opera 8.00 [en]

More detailed information about creating pages, stylesheets & javascripts for Opera on Symbian (along with working examples) may one day appear if development of this site resumes. This page is only really about user agent strings with a few quick thoughts about browser sniffing attached.

All material Copyright © 2003 Mobile Opera. All rights reserved.