Why does your brand color look different on every phone?

You chose the color on a MacBook, checked it in the simulator, and shipped. Then a friend sends a photo of your app on their Galaxy and the gold has gone orange, and the App Store screenshots on an office monitor look like they were left out in the sun. Nothing is broken. The hex code you picked was never a color. It's a coordinate, and at least three separate systems between your design file and someone's eyes get a say in what color it turns into.

A hex code is a coordinate, not a color

#F2C14E is three numbers between 0 and 255. Numbers only mean something inside a color space, and the space almost everything assumes is sRGB, a 1996 standard sized to the CRT monitors of the day. Display P3, Apple's variant of the cinema DCI-P3 gamut, covers about 25% more area on the standard chromaticity chart. The extra room is almost entirely in saturated reds and greens; the blue primary is the same one sRGB uses.

Every iPhone since the iPhone 7, current Macs, and most flagship Androids have a P3 panel. So the screen can show colors the number can't describe, and the entire pipeline has to answer one question: does #F2C14E mean "this exact sRGB color," or does it mean "this much of whatever the panel can do"? The first reading gives you the color you chose. The second stretches it toward the edge of the gamut, which for a warm gold means more orange, more saturated, and further from what your Windows-using customers see.

The file: tagged or untagged

An image either carries a color profile or it doesn't. PNG stores one in an iCCP chunk; JPEG embeds an ICC profile the same way. Untagged means "guess," and every major browser, along with iOS, guesses sRGB. A screenshot taken on a modern iPhone is tagged Display P3, and the pixel values inside it are P3 values. If a tool along the way strips that tag, the same numbers get read as sRGB and the whole image goes slightly flat. If the tool keeps the tag but composites the screenshot onto an sRGB background without converting, one of the two layers is now wrong, and you won't spot which until it's on the listing.

The distinction that matters is assign versus convert. Assigning a profile changes the label and leaves the numbers alone. Converting recalculates the numbers so the color survives the move. macOS ships a converter in the terminal:

sips --matchTo "/System/Library/ColorSync/Profiles/sRGB Profile.icc" shot.png --out shot-srgb.png

That takes a P3-tagged screenshot, converts its pixels into sRGB, embeds the sRGB profile, and writes a file that reads the same everywhere sRGB is assumed. Anything that fell outside sRGB is clipped to the nearest edge, which for a UI screenshot is usually nothing.

The pipeline: managed by default, wide by opt-in

Files are half the story. The code that draws your interface is the other half, and the platforms mostly agree on the default while disagreeing on how you get past it.

iOS color-manages everything. A color built from sRGB components renders as that sRGB color on a P3 panel, and wide color is opt-in: the Display P3 initializer on UIColor, or an asset catalog image set tagged for the Display P3 gamut with an sRGB version alongside it. Android has been color-managed since 8.0, with wide color switched on per activity via android:colorMode="wideColorGamut", and the docs warn that it costs memory and GPU time. Flutter renders sRGB unless you're on Impeller and set the FLTEnableWideGamut flag in Info.plist. CSS treats hex as sRGB; wide color needs color(display-p3 …), which Safari has honored since 10.1 and Chrome and Firefox only since versions 111 and 113, both in 2023.

The common thread: on a well-behaved pipeline, sRGB is the default and a hex code lands as the color you meant. The shifts come from the places that aren't well-behaved.

The panel: the setting you don't control

Samsung's Galaxy phones have a Screen mode setting with two choices. Natural targets sRGB. Vivid maps everything toward the wider DCI-P3 gamut, so sRGB content is stretched: your gold gets pushed toward orange, your teal toward cyan, and every photo in every app gets the same treatment. It's a display-level setting. Your app has no say in it, and you're shipping into whichever mode each user happens to have it on.

That's the ceiling on this whole exercise. You cannot make one color look identical on every phone, because one of the variables belongs to the user. What you can do is make sure your color is still recognizably your color under both readings.

The design-tool trap

Figma gives each file a color profile, sRGB or Display P3. For most of Figma's life there was a third state, Unmanaged, which was retired in August 2023. In an unmanaged file on a P3 MacBook, sRGB numbers went straight to the panel without conversion, meaning stretched. Designers picked a color by eye, watched it glow, and shipped the hex. Everywhere sRGB was honored, including every iPhone, it came out a little duller than the mockup. If your brand color predates that change and has always looked "flat" outside the design file, this is the likely reason.

Figma's own help center says P3 represents 49% more visually distinct colors than sRGB. True, and also a trap: a brand color that only exists in P3 has no exact sRGB equivalent, so it gets clamped on every sRGB surface it meets, and a great many of the surfaces where people meet your brand are sRGB.

What to actually do

Pick the color in sRGB. If it has to be reproducible on the web, on Windows, in an email, and in a Play Store listing on a mid-range Android, it lives in sRGB. Use P3 the way the platforms intend it: for photography, and for accents with a designed sRGB fallback, such as an asset catalog gamut variant or a CSS @media (color-gamut: p3) rule.

Keep it away from the gamut edge. The colors that shift most are the saturated ones near sRGB's boundary, because stretching has room to move them. A brand color with a little headroom moves less under Vivid and clips less coming back from P3.

Convert everything you export. Untagged is a coin flip, and assigned is a lie. Convert to sRGB and embed the profile, and the file reads the same on every managed surface.

Export store screenshots in sRGB. Apple's screenshot spec sheet says JPEG or PNG with no alpha channel and nothing at all about color space. The uploader accepts a P3-tagged file, and you find out how it was interpreted by looking at the listing on three devices. Google Play takes JPEG or 24-bit PNG with the same silence. sRGB makes the worst case "slightly less vivid than your Mac," which nobody notices. The other worst case is a set of frames whose backgrounds don't match the app icon sitting next to them.

Test the two extremes, then stop. An iPhone, which is color-managed P3, and a Galaxy set to Vivid. If the color reads as your color on both, ship. If it reads as a different color on one of them, the fix is the color, not the pipeline: move it inward.

Where this compounds: your store screenshots

Store screenshots are the one place every layer above stacks up at once: an iPhone capture tagged P3, dropped onto a background chosen in a design tool, exported by a third tool, and viewed on every kind of panel right beside your icon. ShotCanvas composes and exports in sRGB on both platforms, with no wide-gamut mode switched on, so the numbers you see in the editor are the numbers the stores receive. Pick a color with headroom and the set will still read as one set on a Vivid Galaxy and a color-managed iPhone.