Description of the issue: How can this issue be reproduced?
Have at least one HDR-enabled screen and one not HDR-enabled
Open brave and move the window from the HDR screen to the non-HDR screen. (Alternatively turn HDR off on the HDR-enabled screen)
Color saturation on Brave browser shoots up by several orders, making it unpleasant to use and borderline illegible.
Expected result: The look and usability of the browser to remain the same
Brave Version( check About Brave): v1.86.139 (Jan 15, 2026)
Additional Information: Only observed on Brave so far, on Linux Nobara 43 KDE Plasma Desktop edition. Graphics running on an AMD Radeon RX 9060 XT Powercolor Hellhound 16GB.
Pre-posting note: After a suggestion from the forum’s “before you post” box, the workaround or user-end fix is turning Graphics Acceleration off in the browser settings, but I still believe it’s worth bringing this to attention even if it’s classified as low priority.
Top picture is a screen capture before Brave recognizes it has been moved from HDR to Non-HDR, the second picture is after.
Just to confirm since you don’t directly say it but want to be sure, you did try Chrome/Chromium as well? This almost feels like a color space issue like it’s not switching profiles between displays. I wouldn’t know how to fix this on Linux though, not since Wayland, and the only fix I can think of would break HDR video support, but keep it looking right. (So I’d like to know if Chrome itself has the same issue, and see where the devs might want to go from there, because I don’t want to disable HDR Video playback support, but I think forcing sRGB in brave://flags might be a workaround).
On Chrome Version 143.0.7499.192 64-bit, the latest version grabbed from Flatpost just now, the color issue appears not to be present with Graphics Acceleration turned on. At least I see no change, personally.
I couldn’t find any sRGB toggles on the Brave flags menu either.
Yea so without graphics acceleration, Brave can’t enter 10bpc, so it never truly goes into HDR and gets stuck sRGB. (The HDR10 colorspace and one other, requires more than 24-bits, and Chromium in software rendered mode is 24-bits, not 30-bits and higher).
(Don’t set yours the way I’m set, I have a different display topology that requires “scRGB”.)
As a test, change this to sRGB and relaunch Brave. While it will remove HDR video playback abilities, does it look consistent and not overblown? If so, it’s a color space issue, it’s not changing profiles between displays like it should be and is forcing one profile on both (normally when you drag Chrome between windows, it automatically switches the best profile for that display, I’m wondering if Chromium 144 isn’t, and is getting stuck on a profile). By forcing sRGB, HDR and the non-HDR display should look at least remotely similar and not the stark “looking at the sun” image you’re getting.
I will say this, Brave is now on Chromium 144, so 143 may not have the issue (and it might be related to 144, as it seems this build has a few weird things going on for some users).
Thanks for verifying. As I suspected it’s a color space issue. As mentioned, Chrome normally changes this when you cross the halfway mark between monitors. (On Windows it’s very obvious if going between a wide gamut display and one that isn’t, as the colors shift ever so slightly). It sounds as if on Chromium 144, this isn’t working which is why between the two displays, they are no longer consistent, as I’m guessing the HDR display is the primary, and Brave/Chromium 144 is opening on the primary’s space, but never detecting when moved between displays.
Not sure if this is Linux only right now or not, as my Windows PC has one display (I’d have to dig out a monitor from the garage.) Perhaps a dev can look into this?
After a short jaunt into my windows boot on the same system, no, it doesn’t happen on windows. There is a change in color saturation but it happens with or without graphics acceleration or the color profile sRGB flag turned on, and it’s nowhere near as “Catch flashbang” as it is on Linux.
EDIT: I have to make a correction to a previous step. It seems like I skipped a step somewhere. I currently have sRGB forced and the color bloom happened anyway when moving the brave window to my side monitor. So far the only thing that fixes it is turning off hardware acceleration.
Glad you were able to test in Windows. Yea the small shift in saturation means at least on Chromium 144 on Windows, color space stuff is working correctly.
But I do see your edit, that forcing sRGB on Linux did not help, so that now interests me, because it’s not color space then.
@Mattches, ideas? I know more about HDR on Windows than I do on Linux, but it feels like a color space mismatch, but their amendment that forcing sRGB didn’t help rules that out, and their wallpaper I noticed is visually consistent across screenshots, so it’s only in the Brave window itself.
