Png in Chrome Shows a Different Image Than in Safari or Any Desktop App
Key topics
A heated debate erupts over why Chrome displays a PNG image differently than Safari and desktop apps, with some commenters suspecting that Safari is actually applying the ICC profile correctly, while Chrome is not. The original author shares their experience, revealing that Safari ignores the ICC profile on their Mac, iPhone, and iPad, sparking a discussion on color management and browser inconsistencies. As the conversation unfolds, it becomes clear that the web standard for color management is still evolving, with some commenters pointing out that interoperability is improving, while others humorously lament the long-standing issue of browser inconsistencies. The thread is relevant now as it highlights the ongoing challenges of ensuring consistent color representation across different browsers and devices.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
16m
Peak period
42
0-12h
Avg / period
11.8
Based on 47 loaded comments
Key moments
- 01Story posted
Dec 27, 2025 at 11:48 AM EST
6d ago
Step 01 - 02First comment
Dec 27, 2025 at 12:04 PM EST
16m after posting
Step 02 - 03Peak activity
42 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 2, 2026 at 12:19 PM EST
2h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
A good test would be to run a single 100% sRGB red pixel through your image processing pipeline, and then inspecting the resulting PNG file in a hex editor to see what value is encoded.
The WebKit blog from 2016:
WebKit color-matches all images on both iOS and macOS. This means that if the image has a color profile, we will make sure the colors in the image are accurately represented on the display, whether it is normal or wide gamut. This is useful since many digital cameras don’t use sRGB in their raw format, so simply interpreting the red, green and blue values as such is unlikely to produce the correct color. Typically, you won’t have to do anything to get this color-matching. Nearly all image processing software allows you to tag an image with a color profile, and many do it by default.
[1]: https://webkit.org/blog/6682/improving-color-on-the-web/
https://wpt.fyi/interop-2025
other than the Manifest v3 fiasco, we're probably living in the golden age of web interop
Every year the major browsers get together and agree on a set of "focus areas" that are paint points for browser interoperability. They've been doing it since 2021. I posted the 2025 results. All browsers reached about 99% support for the selected features
The features are voted on by web developers. Basically anyone with a GitHub account can get involved. Here's a blog post with more info about the process https://webkit.org/blog/17320/submit-your-ideas-for-interop-...
For example, JPEG XL has been proposed for Interop a few times before, but never selected. Therefore, Safari remains the only major browser to support it so far.
https://webkit.org/blog/17320/submit-your-ideas-for-interop-...
And yes JPEG XL support is often the most requested feature and the major browsers have responded. Google and Firefox are both willing to take it on but Firefox's biggest concern is with the reference decoder which has some major security flaws. They basically want to wait until libjxl/jxl-rs is performant enough
https://github.com/mozilla/standards-positions/pull/1064
Here's the current issue for that proposal if you want to get involved
https://github.com/web-platform-tests/interop/issues/994
Hopefully they've both finally settled on a reasoning and will stick with it until the end.
There's been a lot of major changes since then though. Like Apple fully adopting JPEG XL and PDF announcing support as well.
I know many in the industry also think that AV2 might be a huge game changer and wanna wait and see how that ends up before choosing what standards to adopt.
And this is a big part of the problem with having Chrome become such a dominant force on the web: people assume that it's correct when Safari displays something differently. And people give instructions and documentation for how to do various things "in HTML/CSS/JS" when they've never tested them in anything other than Chrome, so if Chrome's behavior deviates from the spec there, someone implementing those instructions on Safari will see them fail, and assume incorrectly that it's Safari that's wrong.
Note that I am not saying this is what is happening in any specific case—but because Chrome is so dominant, enough people treat it as the de-facto standard that over time, it becomes a near-inevitability that this will happen in some cases.
Except for printing. Printing has and seemingly always will f'n suck. Unfortunately WPT doesn't have a good way of testing for print-related features
What gets me is that the image he's publishing is not really a PNG kind of image.
[1] https://cybereality.com/rendepth-red-cyan-anaglyph-filter-op... is a write up that didn't go as deep as my research
https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...
PNG: https://webkit.org/wp-content/uploads/srgb-vs-display-p3-int...
That's not how color management is meant to work. The color profile tells you how the data is saved. If you are displaying it using a different color profile, then it needs to be converted. Displaying P3 in sRGB is doing it wrong. How can you conclude Chrome "was not wrong"?
Correct. What's supposed to happen is P3 colors get converted on the fly to the their closest sRGB colors.
Why does the page 404 when opening the image? Bandwidth issue? Firefox issue? (Yes, the username is a joke - I don't work for Firefox I just use it and thought this would be a funny name)
they wayback machine doesn't have a copy of https://lr0.org/i/2025-12-27_18-21-51_screenshot.png or i was going to link to it in the post here usually, i'd try to balance a blunt reply like this with they wayback version
cheers!
https://web.archive.org/web/20251227181428if_/https://lr0.or...
maybe you linked a different picture?
> Plot twist; here was never a gAMA chunk to begin with!
But I do see a gAMA chunk in the file?
> 00 00 00 04 67 41 4d 41 00 03 5b 5e 5c ff 26 78
Which decodes to a gamma of 2.19998. Conversely, I don't see any bundled ICC profiles (iCCP chunks).
What is this nonsense about? I’m on a tablet and over 1/3rd of my screen is basically telling me to go fuck myself?
> (1) The PNG contains an embedded ICC color profile* (likely Display-P3 or another wide-gamut color space),
Why didn't you check? From what I can tell when I did, there is no color profile in the original image so it'll default to sRGB. This really looks like a gamma issue of some sort (see @perching_aix's comment).
https://x42.com/koolefant/
> If you are using Netscape(*) you will probably see the happy cow above. Internet Explorer-users on Windows and Mac, however, will see a dead flat elephant. And this is due to a strange browser-feature.
> (*) or MSIE for Solaris
Yes, Netscape and MSIE on Solaris. This goes back to the 1990s:
https://web.archive.org/web/19990222144857/http://x42.com/ko...
(I'm running Brave Mobile if that matters. I'm curious if the thumbnail is rendered differently on other mobile web browsers as well?)