Opera GX triggers a hydration error in this Next.js app because the HTML rendered on the server does not exactly match what Opera GX produces on the client during hydration.

In the reproduction app, the page works in other browsers but fails in Opera GX, which is a classic signal that some browser-specific behavior, extension-like DOM injection, or client-only value is altering the initial render tree before React can attach to it.

Understanding the Root Cause

A hydration mismatch happens when server-rendered HTML differs from the first client render. Next.js sends HTML from the server, then React hydrates that markup in the browser. If Opera GX modifies the DOM, evaluates browser-specific APIs differently, or causes a different first render path, React detects that the trees do not match and throws a hydration warning or error.

In browser-specific cases like Opera GX, the most common technical causes are:

• Client-only APIs used during render, such as window, document, navigator, localStorage, or browser UA checks.
• Non-deterministic values rendered on the server, such as Date.now(), Math.random(), locale-sensitive formatting, or generated IDs that differ between environments.
• Browser-injected attributes or elements. Opera GX can ship with privacy, ad-blocking, or enhancement features that behave similarly to extensions and may alter the DOM before hydration completes.
• Third-party UI libraries that depend on layout measurement, media queries, or browser globals during the initial render.
• Conditional rendering by user agent that makes Opera GX follow a different branch than Chromium-based Chrome despite both being similar engines.

The key point is this: if the first render is not deterministic across server and client, hydration will break. Opera GX simply exposes the mismatch more aggressively.

Step-by-Step Solution

The safest fix is to make the initial render fully stable and move browser-dependent logic to the client after mount.

1. Reproduce and confirm the mismatch source

Run the app locally from the repository linked in the issue and compare server output with the first browser render:

pnpm install
pnpm run dev

Open the app in Opera GX and check the console for hydration warnings like:

Hydration failed because the initial UI does not match what was rendered on the server.

Then inspect components that render:

• browser data
• dynamic timestamps
• random values
• viewport-dependent UI
• theme or storage state

2. Move browser-only logic into useEffect

If a component reads from window, navigator, or localStorage during render, replace it with client-side state initialized after mount.

import { useEffect, useState } from 'react';

export default function BrowserInfo() {
  const [userAgent, setUserAgent] = useState('');

  useEffect(() => {
    setUserAgent(window.navigator.userAgent);
  }, []);

  return <p>{userAgent || 'Loading browser info...'}</p>;
}

This prevents the server from rendering one value and Opera GX from rendering another before hydration.

3. Guard client-only UI with a mounted flag

For components that depend heavily on browser state, render a stable placeholder first.

import { useEffect, useState } from 'react';

export default function ClientOnlyBlock() {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    setMounted(true);
  }, []);

  if (!mounted) {
    return <div>Loading...</div>;
  }

  return <div>Client-rendered content</div>;
}

This is one of the most reliable ways to stop browser-specific first-render mismatches.

4. Disable SSR for truly browser-bound components

If a component cannot render safely on the server, load it dynamically with SSR disabled.

import dynamic from 'next/dynamic';

const OperaSensitiveComponent = dynamic(
  () => import('../components/OperaSensitiveComponent'),
  { ssr: false }
);

export default function Page() {
  return <OperaSensitiveComponent />;
}

Use this carefully. It fixes hydration issues, but it also removes server-side rendering benefits for that component.

5. Remove non-deterministic values from the initial render

Avoid code like this in server-rendered JSX:

export default function BadExample() {
  return <div>{Date.now()}</div>;
}

Instead, compute those values after mount:

import { useEffect, useState } from 'react';

export default function StableTime() {
  const [time, setTime] = useState('');

  useEffect(() => {
    setTime(String(Date.now()));
  }, []);

  return <div>{time || 'Loading...'}</div>;
}

6. Check theme, storage, and media query logic

Opera GX users often have custom theme, dark mode, or browser-side enhancement features enabled. If your app renders based on a stored theme before hydration, server and client may disagree.

import { useEffect, useState } from 'react';

export default function ThemeLabel() {
  const [theme, setTheme] = useState('light');

  useEffect(() => {
    const stored = localStorage.getItem('theme');
    if (stored) setTheme(stored);
  }, []);

  return <div>Current theme: {theme}</div>;
}

If you use a theme library, make sure it supports Next.js hydration-safe rendering.

7. Use suppressHydrationWarning only for unavoidable text differences

If a small text node must differ between server and client, you can suppress the warning:

<span suppressHydrationWarning>
  {typeof window === 'undefined' ? '' : window.navigator.userAgent}
</span>

This is not a real fix for structural mismatches. Use it only when the difference is intentional and isolated.

8. Audit third-party components

If the reproduction app uses external UI packages, temporarily remove them one by one. Libraries that measure viewport size, inject IDs, or rely on browser APIs during render are frequent hydration offenders.

// Test by replacing the suspect component
export default function Page() {
  return <div>Minimal stable render</div>;
}

If the error disappears, the third-party component needs a client-only wrapper or an SSR-safe configuration.

9. Test Opera GX with blockers or browser features disabled

Because this issue is browser-specific, also test with Opera GX built-in blockers or enhancement features disabled. If that changes behavior, the browser is likely mutating the DOM or timing of scripts in a way that exposes a latent mismatch in the app.

That does not mean the app is correct. It usually means the app already had a fragile hydration path that other browsers tolerated.

10. Preferred production fix pattern

For most Next.js apps, the cleanest fix is:

1. Keep server HTML static and deterministic.
2. Move browser-dependent logic into useEffect.
3. Render a stable fallback before mount.
4. Use dynamic import with ssr: false only when necessary.

import { useEffect, useState } from 'react';

export default function SafeComponent() {
  const [mounted, setMounted] = useState(false);
  const [ua, setUa] = useState('');

  useEffect(() => {
    setMounted(true);
    setUa(navigator.userAgent);
  }, []);

  if (!mounted) {
    return <div>Loading...</div>;
  }

  return <div>Browser: {ua}</div>;
}

Common Edge Cases

• Locale formatting differences: toLocaleString(), date formatting, and number formatting can differ between server runtime and browser.
• Generated IDs: custom ID generation during render can differ if the order of renders changes.
• Feature detection in JSX: checks like if (navigator.userAgent.includes(...)) inside render can split the tree between server and client.
• Theme flicker logic: reading dark mode or saved theme too early can create different class names or text content.
• Third-party ads, analytics, or widgets: scripts that mutate the DOM before hydration can break React attachment.
• Strict Mode confusion: React Strict Mode can make debugging noisier in development, but it is usually not the root cause. The real issue is still render mismatch.
• Browser extensions or built-in blockers: Opera GX may expose DOM mutations that do not appear in a cleaner browser profile.

FAQ

Why does this only happen in Opera GX if the app works in Chrome?

Because hydration bugs are often latent. Opera GX may inject, block, or evaluate something slightly differently, which makes the mismatch visible. The app is typically relying on unstable first-render behavior that should be fixed regardless of browser.

Should I fix this with ssr: false everywhere?

No. Disabling SSR everywhere hides the problem and can hurt SEO, performance, and time-to-content. Use it only for components that truly require browser APIs during initial rendering.

How do I know whether the problem is my code or the browser?

Start from a minimal stable component and add code back gradually. If removing browser-dependent logic fixes the issue, the mismatch is in the app. If the issue only appears with specific Opera GX features enabled, the browser may be exposing an existing hydration weakness rather than creating it from nothing.

The practical fix for this GitHub issue is to make the first render SSR-safe, avoid browser-only values in JSX, and isolate Opera-sensitive components behind client-side rendering boundaries. Once the markup is deterministic, Opera GX will hydrate the page the same way as other browsers.