Files used by Opera

Last update: June 1, 2011

This document identifies files used by Opera 10.0x and later release versions for Mac, UNIX, and Windows operating systems. It can be useful for those who like to manually adjust their copy of Opera.

Please note Opera Unite and Opera Widgets will be disabled by default in Opera 12.00 and unavailable as of Opera 12.50. More information about this is available here.

Voice support will be removed as of Opera 12.00, as the voice-detection library is no longer supported by the third-party vendor.

BitTorrent will not be available in the MacOS version of Opera as of Opera 12.00.

On this page...

File name changes

Some Opera file names have changed starting with the release of Opera 10.0x.

Cross-platform file name changes

Old file name New file name
speeddial_defaults.ini standard_speeddial.ini
accounts_defaults.ini standard_accounts.ini

Mac file name changes

Old file name New file name
Opera 9 Preferences operaprefs.ini
Opera Direct History typed_history.xml
Opera Global History global_history.dat
Bookmarks bookmarks.adr
Site Preferences override.ini

UNIX file name changes

Old file name New file name
opera6.ini operaprefs.ini
opera6rc operaprefs_default.ini
opera6rc.fixed operaprefs_fixed.ini
opera6.adr bookmarks.adr
english.lng en.lng (it is also in the locale/en folder ONLY)

Windows file name changes

The general path to these files is:

Old file name New file name
opera6.ini operaprefs.ini
OperaDef6.ini operaprefs_default.ini
Opera6.ini operaprefs_fixed.ini
opera6.adr bookmarks.adr
english.lng en.lng (it is also in the locale/en folder ONLY)
images (folder in app data, etc.) icons

Customizing with the Preferences Editor

Opera recommends using the opera:config Preferences Editor to customize your copy of Opera.

  1. Start Opera.
  2. Type opera:config in the Opera address bar.
  3. Press Enter.

This will open the Opera Preferences Editor with the following items that you can adjust. Note: Each item is hyperlinked to its place in the Opera Preferences Editor.

Manually editing files

Warning: Manual editing of these files can make your copy of Opera unusable, or cause data loss. Do not tweak while Opera is running, except when told otherwise. Deleting files will cause data loss! Always make backups before making any changes.

Mac-specific items: The Opera.app package is securely signed. Any modifications to the contents within the package will break the seal, and may result in security warnings from the system firewall every time Opera starts up. You may change the package name and set attributes for it in Finder.

Platform package resources and preferences

Reference is made to two locations for resources:

Mac application package

Folder Description
/Application/Opera.app This is the default install location.

Mac application package breakdown

Folder Description
Opera.app/Contents/Resources This is the location for default resources.
Opera.app/Contents/Resources/defaults These are the default .ini and .xml files.
Opera.app/Contents/Resources/images These are several images currently used as video controls.
Opera.app/Contents/Resources/skin These are skin files.
Opera.app/Contents/Resources/styles These are style files, with user styles in a subfolder.
Opera.app/Contents/Resources/lang_code.proj These are localized resources using the system language code.
Opera.app/Contents/Resources/unite These are the default and available Opera Unite applications.
Opera.app/Contents/Resources/widgets These are default widgets to be installed, if included.

Mac preferences

Folder Description
~/Library/Application Support/Opera Any user data of significant size should be placed here.
~/Library/Caches/Opera Any temp/cache data should be placed here.
~/Library/Opera All other preferences should be placed here.
THE NEXT TWO SEEM OUTDATED THE NEXT TWO SEEM OUTDATED
~/Library/Preferences/com.operasoftware.Opera.plist These are the system window and dialog settings.
~/Library/Preferences/com.operasoftware.OperaWidgets.plist This is the reference list of installed widgets.

Mac system

Folder Description
/Applications/Opera.app/Contents/PlugIns/ These are plug-ins that are bundled with Opera.
/Library/Internet Plug-Ins These are plug-ins that are controlled by the system.
~/Library/Internet Plug-Ins These are plug-ins that are controlled by the user.
/Library/Preferences/Opera Preferences [1] These are system-wide preferences for all Opera installations.
/Library/Preferences/Opera Preferences/Fixed [1] These are system-fixed, overridden preferences for all Opera preferences.

[1] These are never set up with the installation. The files must be manually placed here by a system administrator.

UNIX package

UNIX users please note:

Folder Description
${PREFIX}/bin/opera This is the wrapper script to launch Opera.
${PREFIX}/bin/opera-widget-manager This is the wrapper script to launch the Opera Widget Manager.
${PREFIX}/bin/uninstall-opera This is the wrapper script to uninstall Opera (for tar packages only).
${PREFIX}/lib/opera These are the binaries.
${PREFIX}/lib/opera/plugins This is the plug-ins install location.

UNIX package breakdown

UNIX users please note:

Folder Description
${PREFIX}/share/opera/locale These are localized files all in subdirectories following the system language codes.
${PREFIX}/share/opera/skin These are the skin files.
${PREFIX}/share/opera/styles These are style files, with user styles in a user subdirectory.
${PREFIX}/share/doc/opera These are licenses.
${PREFIX}/share/icons/hicolor These are icons.
${PREFIX}/share/man/man1 These are man pages.
${PREFIX}/share/pixmaps These are pixmaps (for deb package only).

UNIX preferences

Folder Description
~/.opera Any user data is placed here.

UNIX system

Folder Description
/etc These are system-wide resources (operaprefs_default.ini and operaprefs_fixed.ini)

Windows package

When Opera is installed with the single user option
When Opera is installed without the single user option

Windows package breakdown

Path Description
Opera\ This is the installation location.
Opera\*.exe;Opera\*.dll This is the actual executable file.
Opera\operadef6.ini These are the default Opera settings.
Opera\english.lng This is the fallback human language.
Opera\search.ini These are the default searches.
Opera\license.rtf This the license for a language selected during installation.
Opera\defaults\ These are all other .ini files, default bookmarks, and other settings.
Opera\locale\ These are all of the languages.
Opera\locale\*\*.lng These are language files for other languages.
Opera\locale\*\license.txt These are the localized licenses.
Opera\program\plugins\ These are plug-ins installed by Opera, or by other programs aware of Opera.
Opera\Skin These are the default installed skins.
Opera\Styles These are the default installed cascading style sheets.
Opera\Widgets These are the default installed widgets.

Windows preferences

Profile type Registry value Description
Roaming AppData Only a small amount of data can be put here; the roaming profile is limited to a maximum of 30 MB.
Local Local AppData The rest of the user data can be placed here.

Windows system

Platform specifics

Mac

Path Description
Opera.app/Contents/PlugIns These are plug-ins used within Opera (Java and PDE). Do not confuse this with Flash, etc.

UNIX

UNIX users please note:

Folder Description
${PREFIX}/lib/opera/plugins This is the plug-ins install location.
${PREFIX}/share/opera/uninst This is an uninstallation file.
${PREFIX}/share/doc/opera These are licenses in English only, and a copy from locale/en.
${PREFIX}/share/icons/hicolor These are icons.
${PREFIX}/share/man/man1 These are man pages.
${PREFIX}/share/pixmaps These are pixmaps.

Windows

Path Description
Opera\program\plugins\ These are plug-ins installed by Opera, or by other programs aware of Opera.

Layout folders

The following sections describe each system's layout folders.

UNIX users please note:

Binaries

System Folder Description
Mac <installation path>/Opera.app/Contents/MacOS
<installation path>/Opera.app/Contents/Frameworks
Mac binaries
UNIX ${PREFIX}/lib/opera/ UNIX binaries
Windows <installation path>\Opera\ Windows binaries

Resources

UNIX users please note:

System Folder Description
Mac Opera.app/Contents/Resources Root of Opera resources on Mac
UNIX ${PREFIX}/share/opera/ Root of Opera resources on UNIX
Windows Opera\ Root of Opera resources on Windows

Package breakdown

The <package> folder is listed (as above) for the different platforms.

Folder Description
<package>/aux These are auxiliary files that are needed, but should be moved.
<package>/defaults These are default settings and fallback files.
<package>/java These are Java files.
<package>/scripts These are script files.
<package>/skin These are skin files.
<package>/styles These are style files, with user styles in a subfolder.
<package>/ui These are user interface files, such as keyboard, dialog, and toolbar.
<package>/unite These are the Opera Unite services files.
<package>/locale/lang_code These are localized resources using the system language code (UNIX/Windows platforms only)
<package>/lang_code.proj These are localized resources using the system language code (Mac platform only)
<package>/widgets These are default widgets to install if they are included.
<package>/custom Any custom resources are here, situated one directory lower.

Opera file formats

This section describes the binary file formats used in cache and cookie management.

The new generic format that these files are based on is structured as a sequence of tagged records with a given length. Each record may contain a number of different data types such as strings and integers, as well as arbitrary binary data, such as new records in this format.

The generic format is NOT backwards compatible with Opera 3.x and earlier, but is intended to be reasonably backwards compatible for version 4.0 and later. This means that if new fields are added by a future version, older versions will still be able to read the information that they understand, while ignoring the fields they do not understand.

There are some limits, but they are mostly concerned with the number of significant bits in the integers that are used to indicate record lengths. The formats are presently used to store the disk cache index file (dcache4.url), the visited links file (vlink4.dat), the download rescue file (download.dat) and the cookie file (cookies4.dat). The formats are described in the following sequence:

The formats for the windows history, news files and global history files are the same as the ones used by Opera v3.x and are outside the scope of this document.

Generic binary format

Data types

Integers used in the format are unsigned, and stored in big-endian/network style (Most Significant Byte first). Integers stored inside the records are also stored in the big-endian format, but may be signed, and may be truncated.

The following datatypes are used in this document:

Datatype Description
int* This is a signed integer of * bits.
uint* This is an unsigned integer of * bits.
byte This is a 8 bit unsigned value.
string This is a sequence of characters (not null terminated).
time_t This is uint32 representing a time value in seconds since 00:00 Jan 1, 1970 GMT. The representation may be increased past 32 bit in the future.
tag_id_type This is an unsigned integer whose size is selected by the idtag_length header field. The application must convert from this type to its internal unsigned integer representation, preferably uint32. For more information, see the file header format.
payload_length_type This is an unsigned integer whose size is selected by the length_length header field. The application must convert from this type to its internal unsigned integer representation, preferably uint32. For more information, see the file header format.
record This is a separately defined sequence of fields.

Data records

The general record format has the following form:

struct record
{
// application specific tag to identify content type
tag_id_type tag_id;
// length of payload
payload_length_type length;
// Payload/content of the record
bytepayload[length];
};

NOTE: The number of bytes in tag and length may change, see below.

The fields of each record have the following meanings:

tag_id

The identifier of the record. This value is application specific, and can be used to indicate the meaning of the payload content.

The actual content type of the record depends on the definitions used for the actual file or super-record.

Tag_id values in which the MSB (Most Significant Bit) is set to 1, are reserved for records with implicit no length. The tag_id field is NOT followed by a length field, nor a payload buffer. Such records are used as Boolean flags: True if present, False if not present.

In the binary storage of a file this means that the MSB of the internal storage integer must be stored as the MSB of the first byte in the tag field. This places a limit on how many tags can be used for a given tag_id integer length. When a file is read into a program, the program must take care to move the MSB of the binary stored tag to a common (internal) bit position, such as the MSB of the program's own unsigned integers.

bytes This is the max id available (excluding MSB).
1 0x7f
2 0x7fff
3 0x7fffff
4 0x7fffffff

While it is technically possible to use the same tag id (without the MSB) for a normal record and a flag record (such as 0x0001 [16 bit tag] for the payload record and 0x8001 for the flag record), this is not encouraged.

length
This field is the number of bytes in the payload that immediately follow the field. It may be zero.
payload

The payload is a sequence of bytes of the length indicated by the length field.

The meaning of the contents is indicated by the definition for the given record or file structure. Examples of organization may be an array of records, unsigned integers, signed integers, or characters.

It is recommended that only records of the types described here are used if the type of the data varies, as variable (un-tagged) type formats tend to be inflexible and difficult to maintain across versions, especially when compatibility with older versions is desired.

Single item integers (signed or unsigned) may be truncated (zero bytes removed), but arrays of integers must always use a fixed number of bytes to represent values and derive the number of items from the payload length. If the number of bytes needed to represent the values changes in a future version a new tag should be used.

File Format

These elements are not stored as records, but directly in binary:

uint32 file_version_number;
uint32 app_version_number;
// number of bytes in the id tag, presently 1
uint16 idtag_length;
// number of bytes in the length part of a record, presently 2
uint16 length_length;
// array of records, number determined by length of file
struct record items[];

The present version number of the file format (file_version_number) is 0x00001000, where the lower 12 bits (bitmask 0x00000fff) represent the minor version number, the rest is the major version number. Changes in the minor version must not be used if the file format is changed in such a manner that older versions of the software cannot read the file successfully. If the major version number is newer (or older) than the application can read, it must not read the file.

The integer sizes are absolute for a given major version, and the integer size for the file version number is fixed in any version.

The "app_version_number" is the version number of the application and is independent of the file_version_number. It may be used by the application to determine necessary actions needed to provide forward or backward compatibility that is outside the scope of the file formats. The interpretation of the application version number is application dependent.

The "idtag_length" and "length_length" fields gives the number of bytes used in the records for the idtags, as defined by the tag_id_type, and the payload length fields, as defined by payload_length_type, respectively.

Specifically, the values of these fields define tag_id_type and payload_length_type as the following integer types:

Value tag_id_type payload_length_type
in idtag_length length_length
1 uint8 uint8
2 uint16 uint16
3 uint24 uint24
4 uint32 uint32

The application's internal representation of these types is not defined, but uint32 is recommended. How an application should handle "idtag_length" or "length_length" values larger than 4, or values larger than its internal unsigned integer size, is not defined, but the application should implement the rules specified in the forward compatibility guide for such situations.

Present versions of Opera 4.x uses idtag_length=1 (uint8) and length_length=2 (uint16).

After the header, only records follow. The organization of the records and their interpretation is application specific.

Forward Compatibility

An older version of an application using this file format that is NOT able to use long integers should, regardless of this, try to process the file, but should bypass the record if the tag of the record's numerical value exceeds the version's own integer range, i.e. the integer overflows. However, if the the length of the record exceeds the application's limits on integers or buffer capabilities, it must not continue to process the file.

All applications must ignore tag values that they do not understand.

Cache file formats

This section details the record tags and formats used for the visited link file (vlink4.dat), the disk cache index file (dcache4.url) and the download rescue file (download.dat). The present app_version_number of these files is 0x00020000 (major version 2, minor 0).

These files use records (of different tag values) which contain a sequence of records with tags from the same set of tag ids. The different files use these tags for their records:

File Tag id Version number
Disk cache 0x01 0x00020000
Visited Links 0x02 0x00020000
Download 0x41 0x00020000

Each file consists of records of ONLY this type, with the exception of the Disk cache index file, which also contains a single record with the id 0x40, which contains a 5 character string used to find the next free cache file number (oprXXXXX).

Each record is again a sequence of records with the same binary representation format as the records in the file.

Common elements between all files

These elements are used by all of the cache related files. In the case of visited links, these are the only fields presently used.

NOTE: "(0x0001 | MSB_VALUE)" means that the most significant bit in the local unsigned integer is to be set. If 32 bit values are used, that means the tag's value is 0x80000001.

Tag ID Contents Meaning
0x0003 string This is the name of the URL, fully qualified.
0x0004 time_t This is last visited.
0x000b MSB_VALUE: flag The URL is a result of a form query.
0x0022 record Contains the name and last visited time of relative link in the document; it may repeat.

Content tags of relative link (tag 0x0022) records

Tag ID Contents Meaning
0x0023 string This is the name of the relative link.
0x0024 time_t Last visited.

Fields used by disk cache and download rescue files

Tag ID Contents Meaning
0x0005 time_t This is localtime, when the file was last loaded; it is not GMT.
0x0007 uint8 Status of load:
2 - Loaded
4 - Loading aborted
5 - Loading failed
0x0008 uint32 This is content size.
0x0009 string This is the MIME type of content.
0x000a string This is the character set of content.
0x000c MSB_VALUE: flag File is downloaded and stored locally on a user's disk; it is not part of the disk cache directory.
0x000d string This is the name of the file (cache files: only local to cache directory).
0x000f MSB_VALUE: flag Always check if modified.
0x0010 record This contains the HTTP protocol specific information.
0x0050 uint16 ("len") Embedded URLs: This signifies that the URL is stored in the cache index. It is a uint16 ("len") followed by an array of "len" bytes that represent the content of the URL.
0x0052 uint32 Identifies the network type from which a given resource has been loaded.
  • 0: localhost
  • 1: private
  • 2: public
  • 3: undetermined
0x0053 MSB_VALUE: flag Used to detect if the MIME type was initially empty.
0x002B string This is FTP Modified Date Time.
0x002B MSB_VALUE: flag Never flush this URL.
0x0037 uint32 These are associated files.

Fields used only by the download rescuefile

Tag ID Contents Meaning
0x0028 time_t Identifies the time when the loading of the last/previous segment of the downloaded file started.
0x0029 time_t Identifies the time when the loading of the last/previous segment of the downloaded file was stopped.
0x002A uint32 The is the amount of bytes in the previous segment of the file being downloaded. If the time the loading ended is not known, this value will be assumed to be zero (0) and the download speed set to zero (unknown).
0x002C uint32 Enables the ability to resume the downloaded URL.
  • 0: Not resumable
  • 1: May not be resumable (or field not present)
  • 2: Probably resumable

Fields used in the HTTP protocol specific record

All methods are by default GET; at present it is not possible to cache POST requests.

Tag ID Contents Meaning
0x0015 string HTTP date header
0x0016 time_t Expiry date
0x0017 string Last modified date
0x0018 string MIME type of document
0x0019 string Entity tag
0x001A string Moved to URL (Location header)
0x001B string Response line text
0x001C uint32 Response code
0x001D string Refresh URL
0x001E uint32 Refresh delta time
0x001F string Suggested file name
0x0020 string Content Encodings
0x0021 string Content Location
0x0025 uint32 Together with tag 0x0026 (both must be present), this identifies the User Agent string last used to load the resource. This value identifies the User Agent string. This value is used internally, and should not be modified.
0x0026 uint32 Together with tag 0x0025 (both must be present), this identifies the User Agent string last used to load the resource. This value identifies the User Agent sub version. This value is used internally, and should not be modified.
0x0030 MSB_VALUE: flag Reserved for future use.
0x0031 MSB_VALUE: flag Reserved for future use.
0x002F MSB_VALUE: flag Always validate before displaying, also when moving in history.
0x002D string This signifies a link relation.
0x002E string This signifies content language.
0x003A uint32 This signifies a HTTP age header.
0x003B structure This signifies a list of HTTP headers. It is a sequence of 0x003C records (headers from an HTTP response).
0x003C structure This signifies a single HTTP Header. It is a sequence of a single 0x003D record and a single 0x003E record.
0x003D string This signifies the name of the HTTP header.
0x003E string This signifies the value of a HTTP header.

Cookie file format

This section describes the record tags and formats used for the storage of cookies (cookies4.dat). The present app_version_number of this file type is 0x00002000 (major version 2, minor 0).

The cookie file is organized as a tree of domain name components, each component then holds a tree of path components and each path component may contain a number of cookies.

NOTE: The components are a sequence of records, terminated with a flag record, not a single record.

Domain components

The domain components are used to organize the cookies for each server and domain for which cookies or cookie filtering capabilities are defined.

A domain component is started with a domain record, which holds the domain name and some flags for that particular domain. It is then followed by a path component holding the cookies and subdirectory path components (and cookies), followed with a path component terminator and any number of subdomain components before it is terminated by a domain-end flag record.

E.g: cookies for the domain www.opera.com will be stored in this manner:

["com" record]
  ["opera" record]
["www" record
  [cookies]
  [Path components]
  [Path component terminator]
  [other domains]
[end of domain flag ("www")]
  [end of domain flag ("opera")]
[end of domain flag ("com")]

All names of domain components are non-dotted except IP addresses, which can only be stored with the complete IP address as a Quad dotted string, e.g. "10.11.12.13" are stored at the top level and cannot contain any subdomains.

A Domain Record uses the tag "0x01" and contains a sequence of these fields:

Tag ID Contents Meaning
0x001E string This is the name of the domain part.
0x001F int8 This is how cookies are filtered for this domain; if not present, the filtering of the parent domain is used.
  1. All cookies from this domain are accepted.
  2. No cookies from this domain are accepted.
  3. All cookies from this server are accepted. Overrides 1 and 2 for higher level domains automatics.
  4. No cookies from this server are accepted. Overrides 1 and 2 for higher level domains.
Domain settings apply to all subdomains, except those with a server specific selection.
0x0021 int8 This is the handling of cookies that have explicit paths which do not match the URL setting the cookies. If enabled in the privacy preferences the default is to warn the user, but when warning is enabled such cookies can be filtered by their domains: Value 1 indicates reject, and 2 is accept automatically.
0x0025 int8 While in the "Warn about third party cookies" mode, this field can be used to automatically filter such cookies.
  1. All third party cookies from this domain are accepted.
  2. No third party cookies from this domain are accepted.
  3. All third party cookies from this server are accepted. Overrides 1 and 2 for higher level domains automatics.
  4. No third party cookies from this server are accepted. Overrides 1 and 2 for higher level domains.
Domain settings apply to all subdomains, except those with a server specific selection.

This record can be followed by zero or more path components defining toplevel paths on servers in the domain and always terminated by a path component terminator record. Then zero or more domain components may follow.

A domain component is terminated by a (0x0004 | MSB_VALUE) flag record.

Path components

The path components organize the cookies defined for a given directory in a given domain, as well any subdirectories of this directory that have cookies defined.

Except for the path component starting immediately after the domain component record, each path component always starts with a path record, and is then followed by any number of cookie records and subdirectory path components.

The path record uses the record id "0x0002", and the record has this field record:

Tag ID Contents Meaning
0x001D string This is the name of the path part.

The path component terminator is the (0x0005 | MSB_VALUE) flag record.

Cookie Records

The cookie entries are stored in records of type "0x0003" and have the following field records:

Tag ID Contents Meaning
0x0010 string This is the name of the cookie.
0x0011 string This is the value of the cookie.
0x0012 time_t This is the expiry date.
0x0013 time_t This is shows when last used.
0x0014 string This is the Comment/Description of use (RFC 2965).
0x0015 string This is the URL for Comment/Description of use (RFC 2965).
0x0016 string This is the domain received with version=1 cookies (RFC 2965).
0x0017 string This is the path received with version=1 cookies (RFC 2965).
0x0018 string This is the port limitations received with version=1 cookies (RFC 2965).
0x0019 MSB_VALUE: flag The cookie will only be sent to HTTPS servers.
0x001A int8+ This is the version number of a cookie (RFC 2965).
0x001B MSB_VALUE: flag This cookie will only be sent to the server that sent it.
0x001C MSB_VALUE: flag This is reserved for delete protection: not yet implemented.
0x0020 MSB_VALUE: flag This cookie will not be sent if the path is only a prefix of the URL. If the path is /foo, /foo/bar will match but not /foobar.
0x0022 MSB_VALUE: flag If true, this cookie was set as the result of a password login form, or by a URL that was retrieved using a cookie that can be tracked back to such a cookie.
0x0023 MSB_VALUE: flag If true, this cookie was set as the result of a HTTP authentication login, or by a URL that was retrieved using a cookie that can be tracked back to such a cookie.
0x0024 MSB_VALUE: flag In "Display Third party cookies" mode this flag will be set if the cookie was set by a third party server, and only these cookies will be sent if the URL is a third party. Cookies that were received when loading a URL from the server directly will not be sent to third party URLs in this mode. The reverse is NOT true. NOTE: If a third party server redirects back to the first party server, the redirected URL is considered third party.

Documentation

Opera Help

Need help? Hit F1 anytime while using Opera to access our online help files, or go here.