Figma Colors Don't Match the Website? It's the Color Profile
The short answer: your Figma file is in Display P3 and the browser is rendering sRGB. P3 covers a wider range of colour, so your saturated brand red looks richer on the canvas than the same hex value can possibly look on a web page.
The fix: set the file's colour profile to sRGB. Your canvas will look slightly duller — that is not a regression, it is the canvas finally telling you the truth about what ships.
The part that ruins people's afternoon is how you switch. Figma offers two ways, and picking the wrong one silently rewrites every hex code in your design system. Skip to that if you are mid-fix.
This is one of the most disorienting problems in design work, because every instinct you have points at the wrong thing. The screenshot looks fine. The hex code is right. You check on a second monitor and it looks different again. Nothing is broken, so you start doubting your eyes.
You are not going mad. Two colour spaces are involved and only one of them ships.
What a colour profile actually is
A hex code is not a colour. #E95265 is three numbers — how much red, green and blue. It says nothing about how red "full red" is. That depends on the colour space those numbers are interpreted in.
Figma Design supports two:
| sRGB | Display P3 | |
|---|---|---|
| What it is | The long-standing web standard | A wider gamut, ~49% more visually distinct colours |
| Support | Essentially every browser and display | Modern Apple hardware, iOS, newer high-end displays |
| Same hex looks | Normal | More saturated |
| Use for | Web | iOS, controlled display pipelines |
Feed #E95265 to a P3 pipeline and "full red" means a redder red than sRGB can reach. Same numbers, more vivid result. So a P3 Figma file renders your brand colours with a punch that a browser in sRGB simply has no way to reproduce.
The historical footnote that explains a lot of old files: Figma used to have an unmanaged setting, discontinued in August 2023. On a P3-capable Mac, unmanaged files rendered in P3 — which is exactly why so many designers spent years with vivid canvases and flat exports without ever touching a colour setting. Legacy files now fall back to your preferred profile, or sRGB if you have no preference.
The three ways this shows up
1. The export looks washed out next to the canvas
The classic. You export a hero image, open it next to Figma, and it is visibly duller. Nothing is wrong with the export — it is the same design in a narrower colour space, which is what the web is.
2. The hex codes are identical but the page looks wrong
This is the version that makes people question their sanity, because there is no image involved at all. You copy #E95265 out of Figma into your CSS, the browser paints exactly #E95265, and it still doesn't look like the design. It can't. The browser is interpreting those numbers in sRGB and your canvas was interpreting them in P3.
There is no way to fix this in CSS with the same hex value. Either the design moves to sRGB, or you accept the mockup was never achievable.
3. The image looks different from the surrounding page
The most visible failure, and the most embarrassing. A card with a background colour set in CSS sits next to a hero image exported from the same file, and the two are supposed to be the same colour. They are not — the CSS is sRGB, the image carries a P3 profile, and the seam between them is obvious.
If you have ever had a designer point at a "banding" or "edge" between a photo and a solid background, this is usually the cause.
Assign vs Convert — get this right
When you change a file's colour profile, Figma asks how. The two options do genuinely opposite things and the wording does not make the stakes obvious.
| Option | What stays the same | What changes |
|---|---|---|
| Assign (Keep Color Values) | The hex codes | How the colours look |
| Convert (Keep Appearance) | How the colours look | The hex codes |
Figma's own description of Assign: "the colors visually change, but their underlying data—like hex codes or HSB values—stay the same." And of Convert: "the colors' underlying data changes, but will look the same or as similar as possible."
For web work, you almost always want Assign. Your hex codes are the contract. They are in your design tokens, your CSS, your brand guidelines, and probably a Slack message from a year ago. Assign keeps #E95265 as #E95265 and lets the canvas start showing you the sRGB truth about it.
Convert does the opposite, and on a large file that is a lot of damage: every colour value in the document is rewritten to approximate the old appearance. Your brand red is now #EE4A60-something. It does not match your CSS, your tokens, or any other file in your organisation. And going P3 → sRGB, some colours cannot be represented at all, so they get clipped — the conversion approximates them, and no amount of switching back restores the originals.
Duplicate the file before you switch. Convert is not cleanly reversible on a wide-gamut source. Thirty seconds of caution against a design system full of subtly wrong hex codes is not a close call.
The export panel has its own profile setting
Worth knowing separately, because it catches people who have already fixed the file: Figma exports using the file's colour profile by default, but the export panel lets you choose a different one.
So a file correctly set to sRGB can still produce P3 exports if the export profile was changed at some point — often by someone else, months ago, for one asset going to an app team. Check it before a batch export. It is a two-second look and it saves re-exporting forty images.
Why pasted screenshots shift colour
A related annoyance with a different cause. You take a screenshot on a Mac, drop it into Figma, and the colours are not what you captured.
Screenshots carry an embedded profile from the machine that captured them — on modern Apple hardware, usually P3. Drop that into a file using a different profile and Figma reinterprets the numbers against the file's colour space. Nothing was damaged; two colour spaces met and one of them won.
If you are screenshotting a live website to put in a design, this is why the screenshot's blues never quite match the blues in your file. It also means screenshots are a bad reference for colour matching — compare the real thing in a browser, not a picture of it.
When it isn't the colour profile
Before you rebuild your design system, rule these out. They produce a similar complaint.
- You are comparing across two monitors. Two displays, two calibrations, no useful information. Put the export and the live page on the same screen.
- Your monitor is uncalibrated or in a vivid picture mode. Some external displays ship with a saturation-boosted preset. Everything looks great and nothing you produce is trustworthy.
- Night Shift, True Tone, or a blue-light filter is on. These shift white point in real time. Turn them off for any colour work.
- Opacity is stacking. A colour at 90% opacity over a light background is not the hex you picked, and it will not match a CSS value that ignores the layer beneath it.
- Heavy JPEG compression. Aggressive compression shifts colour in flat gradient areas and produces visible banding. If the shift is confined to gradients, this is your cause — see the export settings guide.
What WordPress does to your profile
WordPress does not deliberately change colours. But it does re-encode every upload to generate its thumbnail sizes, and that re-encode goes through whatever image library the server has — GD or ImageMagick — plus any optimisation plugin sitting in the pipeline.
Embedded colour profiles do not always survive that trip. And an image that arrives at the browser without a profile is assumed to be sRGB. For an sRGB image, that assumption is correct and nothing happens. For a P3 image that lost its tag, the browser now reads wide-gamut numbers as if they were sRGB, and the image shifts — usually toward the flat and slightly wrong.
This is the practical argument for exporting in sRGB rather than relying on profile tagging to save you: an untagged sRGB image is still correct. An untagged P3 image is a guess that the browser will get wrong.
Fewer conversions, fewer surprises. Every re-encode between Figma and the live page is another chance for metadata to be dropped. Exporting in sRGB and uploading the finished file directly — rather than export, convert, compress, upload — keeps the number of hops down. It is the same argument as the one for skipping the download step entirely.
The settings to use for web work
| Setting | Use | Why |
|---|---|---|
| File colour profile | sRGB | What browsers assume and what almost every display can show |
| Switching method | Assign | Keeps your hex codes intact for CSS and tokens |
| Export profile | sRGB | Defaults to the file's, but check it — it can be overridden |
| Night Shift / True Tone | Off during colour work | They shift white point live |
| Comparison method | Same screen, side by side | Cross-monitor comparison proves nothing |
One consequence worth naming: after you switch to sRGB, some of your design will look slightly less exciting. That is the point. You are seeing what your users see, which is the only version that was ever going to exist.
FAQ
Why do my Figma colors look different on the website?
The file is in Display P3 and the browser renders sRGB. P3 has a wider gamut, so the same hex values appear more saturated on your canvas than the web can reproduce. Set the file's profile to sRGB and the canvas will match what ships.
What's the difference between sRGB and Display P3?
Two colour spaces. sRGB is the web standard with near-universal support. Display P3 is wider — Figma puts it at 49% more visually distinct colours — and is used on modern Apple hardware and iOS. Some P3 colours have no sRGB equivalent, which is why converting between them can flatten or clip them.
Should I use sRGB or Display P3 for web design?
sRGB. It removes the entire category of problem where the mockup looks better than production ever can. Use P3 when you are shipping to iOS or otherwise control the display pipeline.
Assign or Convert — which do I pick?
Assign, for web work. It keeps your hex codes and lets the appearance shift, so your Figma file, your CSS and your tokens continue to agree. Convert rewrites every colour value in the document to preserve appearance, which breaks that agreement and can clip colours irreversibly.
Why does a screenshot change colour when I paste it into Figma?
The screenshot carries the capturing machine's profile — usually P3 on modern Macs — and Figma reinterprets it against the file's profile. Two colour spaces meeting, not a bug. It also means screenshots are unreliable for colour matching.
Does WordPress change my image colours?
Not on purpose, but it re-encodes uploads to build thumbnails and the embedded profile may not survive, depending on the server's image library and any optimisation plugin. Untagged images are treated as sRGB by browsers — harmless for an sRGB export, wrong for a P3 one. Export sRGB and it stops mattering.
My colours look right on my laptop but wrong on my external monitor.
That is a display calibration difference, not a Figma problem. Compare the export and the live page on the same screen. If you need colour accuracy across displays, calibrate them — and turn off Night Shift, True Tone and any vivid picture mode first.
One less conversion between design and live
Fig2WP takes the export straight from Figma into your WordPress Media Library — no download folder, no third-party converter, no extra re-encode where a colour profile can quietly go missing.