Supporting Opera in Web Apps and Extensions: A Chromium-First Decision Guide

The decision: treat Opera as Chromium, not a special case

If your web app or extension breaks in Opera, the cause is rarely the rendering engine. Modern Opera is Chromium-based, so the standard web platform and Chrome extension APIs are the supported baseline. The real variables are Opera's shell features—especially built-in ad and tracker blocking—and the fact that settings paths and defaults change between Opera One, Opera GX, and stable builds. The practical decision is to stop treating Opera as a special case in code, start treating it as Chromium with an extra blocking layer in validation, and avoid building product logic around features you do not control.

Constraints that shape the choice

• Chromium baseline: Opera 15 and later use the same engine as Chrome. Unless a capability probe fails, assume standard web platform behavior.
• Shell features are not APIs: Built-in ad/tracker blocking, VPN, sidebar, Workspaces, Flow, and account sync are browser-level features, not stable interfaces your site can call.
• Blocking is a runtime variable: Opera's blocker can silently remove third-party scripts, pixels, and fonts. Critical paths such as analytics, authentication, and payments must be tested with blocking enabled and disabled.
• Channels differ: Opera One and Opera GX rename and relocate settings, and default toggles change between releases. Do not generalize a feature observed in one channel to all builds.
• Managed deployment is uncertain: Do not plan enterprise rollouts around Chrome Enterprise policies until policy support is confirmed for the exact Opera build and channel in use.

Comparing support strategies

Approach	Use it when	Main risk	Maintenance cost
Feature-detect, treat as Chromium	Default for all modern Opera	Blocking can hide third-party failures until you test	Low
Read OPR/ in UA for analytics	You need channel-level telemetry	UA strings change; privacy settings can reduce data	Low
Ship a separate Opera extension fork	You need Opera-only UI integration	Chrome Web Store and Opera catalog rules diverge	High
Depend on built-in blocker, VPN, or sidebar	Never for core functionality	Shell features are not stable web APIs	High

Trade-offs behind the table

Feature detection beats UA sniffing

Reading the browser name to change behavior creates brittle code. Instead, probe the capabilities your app actually uses with CSS.supports() and JavaScript feature checks, then log failures. You may read OPR/ from navigator.userAgent or the brands list in navigator.userAgentData, but use that signal only for analytics or documented workarounds—never to gate authentication, payments, or layout.

CSS prefixes and legacy assumptions

Current Opera understands -webkit- prefixed properties. Legacy -o- prefixes target Presto Opera 12 and earlier and are ignored by Chromium-based Opera, so remove them from modern stylesheets. If you still support Opera 12, you are maintaining a separate legacy codebase and should treat it as a distinct browser, not a variant of modern Opera.

Built-in blocking is a runtime variable

Opera's blocker can drop third-party scripts, pixels, and fonts without a visible error in your own code. Never gate an authentication or payment flow behind a third-party domain you do not control. Validate every critical path with the blocker on and off before release, and keep a fallback distribution path for extensions if Opera catalog availability is contractual.

Extensions: one Chromium build, two stores

For extensions, the practical decision is to ship a single manifest v3 Chromium build and distribute it through the Chrome Web Store and Opera's add-on catalog rather than maintaining an Opera-only fork. Opera supports the Chrome extension APIs and DevTools, so a fork adds catalog drift without adding stable capability.

Concrete validation in Opera

Probe capabilities in the console

Open DevTools in Opera, load your page, and run a capability probe. Replace the example API names with the ones your app actually uses.

// Run in the Opera DevTools console on your page.
// Replace the feature list with the APIs your app depends on.
const requiredFeatures = [
  ['serviceWorker', 'serviceWorker' in navigator],
  ['cssGrid', CSS.supports('display', 'grid')],
  ['webShare', 'share' in navigator]
];

const missing = requiredFeatures
  .filter(([, supported]) => !supported)
  .map(([name]) => name);

if (missing.length) {
  console.warn('Missing capabilities:', missing.join(', '));
}

// Analytics-only Opera identification; never gate features on this.
const isOpera = /OPR\//.test(navigator.userAgent) ||
  (navigator.userAgentData?.brands.some(b => b.brand.includes('Opera')));
if (isOpera) {
  console.info('Opera detected for analytics only');
}

Expected check: the console should list only the capabilities your app genuinely requires. If a capability is missing, fix the app or provide a fallback; do not branch on the Opera name.

Diff the Network waterfall with blocking on and off

Opera's built-in ad and tracker blocker is the most common source of silent breakage. Capture a baseline with the blocker disabled, then enable it and capture a second pass.

1. Open DevTools and select the Network tab.
2. Disable Opera's built-in blocking (the exact toggle location varies by version and channel; confirm it in opera://about or Menu > About).
3. Reload the page and export the waterfall as HAR.
4. Re-enable blocking, reload, and export a second HAR.
5. Diff the two files for blocked third-party requests, missing fonts, and console errors.

Risk: if a critical script, pixel, or font disappears only when blocking is on, move that resource to a first-party domain or provide a fallback.

Validate a Chromium extension in Opera

Load your unpacked manifest v3 build directly in Opera to confirm it behaves like Chrome.

1. Navigate to opera://extensions.
2. Enable Developer mode.
3. Choose Load unpacked and select your extension directory.
4. Confirm the manifest v3 service worker registers, requested permissions match Chrome, and any Opera UI integration behaves as expected.

Expected check: the extension should install and run without Opera-specific code. If it does not, the issue is likely a manifest or permission difference, not the Opera engine.

Limitations and a practical release check

• Settings paths drift: Opera One and Opera GX rename and relocate preferences, and default toggles change between releases. Verify names and paths on the installed build before documenting them for users.
• Reduced UA data: navigator.userAgentData is Chromium-based and may be reduced by privacy settings. Do not rely on it alone for security decisions.
• Channel-specific features: A feature observed in Opera GX may not exist in Opera One or stable. Do not generalize.
• Catalog rules change: Chrome Web Store availability and Opera add-on catalog requirements can change. Keep a fallback distribution path if Opera support is contractual.

Before release, run the capability probe, diff the Network waterfalls with blocking on and off, and load the unpacked extension at opera://extensions. If all three pass, you have a supported Opera baseline without maintaining a fork.