The Translation from CMYK to RGB
CMYK to RGB describes the translation from a print-oriented color recipe into an approximate screen color. CMYK describes ink percentages on a printing press: cyan, magenta, yellow, and black, each on a 0 to 100 percent scale. RGB describes the red, green, and blue light intensities used by monitors, encoded as 8-bit channels from 0 to 255 and often serialized as a six-digit hexadecimal value. A CMYK-to-RGB conversion is therefore not a single fixed equation across the industry; it is a family of mappings that depends on the printing press, the ink set, the paper, and the ICC profile that describes each device. The CMYK To RGB tool on this site implements the simplest of those mappings, the W3C "naive" device-CMYK fallback published in the CSS Color Module Level 4 working draft, so that designers can quickly preview how an unprofiled CMYK recipe would look on an sRGB-style display without leaving the browser. It is deliberately labeled an approximation, and it is not a substitute for the profiled workflow that print production demands.
Designers most often look up "cmyk to rgb" when they need a quick screen mockup from a printer-supplied CMYK swatch, when they want to paste a print-only color into a web style sheet, or when they want to see whether two print recipes will look similar enough on screen to share a UI accent. None of those tasks require print-perfect accuracy. They require a fast, predictable, and reproducible preview that they can copy as RGB or hex and paste straight into CSS, a Figma frame, or an email template. Once a color reaches a press approval, a brand spec, or a contractual target, the same preview becomes the wrong tool and a profiled conversion takes over.
Convert CMYK to RGB in Your Browser
The converter follows the same three-step flow every time:
- Set cyan, magenta, yellow, and black to percentages from 0 through 100.
- Read the approximate RGB channels, hexadecimal value, and screen swatch.
- Use an ICC-profile-aware application instead when print accuracy matters.
Open the CMYK To RGB converter and adjust any of the four sliders. The page immediately updates the displayed red, green, and blue channels, the six-digit hex value, and the on-screen swatch. There is no submit button and no upload step. When you have a target, copy the RGB or hex value into your mockup. For a step-by-step walkthrough that uses the same formula, the guide on how to turn CMYK to RGB and preview it on screen covers the same flow with screenshots.
Because every adjustment runs locally, you can iterate quickly: nudge the black slider to compare two near-identical recipes, then snap back to the original CMYK without losing state. That speed is what makes a browser preview useful for the early, exploratory part of a design, before any colors are committed to a press run or a brand spec.
How the W3C Naive Formula Calculates Each Channel
The naive device-CMYK conversion combines each color ink with the black ink before inverting and scaling to the 0 to 255 display range. The formula applied to each of the red, green, and blue channels is:
channel = (1 - min(1, ink × (1 - K) + K)) × 255
where ink is the relevant CMYK color component (C for red, M for green, Y for blue) normalized to 0 to 1, and K is the black component normalized to 0 to 1. The W3C working draft uses half-even rounding so that the well-known firebrick test case resolves to a reproducible integer on every conforming implementation.
A worked example using the W3C firebrick reference, cmyk(0%, 81%, 81%, 23%), walks through the calculation:
- C = 0, M = 0.81, Y = 0.81, K = 0.23
- Red: 1 - min(1, 0 × (1 - 0.23) + 0.23) = 1 - 0.23 = 0.77 → 0.77 × 255 = 196.35 → 196
- Green: 1 - min(1, 0.81 × (1 - 0.23) + 0.23) = 1 - min(1, 0.81 × 0.77 + 0.23) = 1 - 0.8537 = 0.1463 → 0.1463 × 255 = 37.31 → 37
- Blue: same as green because M and Y are equal → 37
- Result: rgb(196, 37, 37), serialized as #C42525
You can verify the result by entering those four percentages into the CMYK To RGB tool and checking that the hex value matches. Any deviation on a conforming implementation points to a different rounding rule rather than a different formula.
Endpoint Behaviors and Test Cases
The naive formula has a small set of predictable endpoints that any conforming implementation must reproduce. The table below lists the cases the W3C spec uses to verify a converter, along with the corresponding screen result.
| CMYK input | Approximate RGB | Hex | Description |
|---|---|---|---|
| 0%, 0%, 0%, 0% | rgb(255, 255, 255) | #FFFFFF | No ink: paper white |
| 0%, 0%, 0%, 100% | rgb(0, 0, 0) | #000000 | Full black: solid black |
| 0%, 100%, 100%, 0% | rgb(255, 0, 0) | #FF0000 | Magenta + yellow, no cyan or black: red |
| 0%, 81%, 81%, 23% | rgb(196, 37, 37) | #C42525 | W3C firebrick reference case |
| 100%, 0%, 0%, 0% | rgb(0, 255, 255) | #00FFFF | Full cyan, no magenta, yellow, or black |
If you reproduce these rows in the converter and the displayed values differ, that is the first sign the tool is using a different formula or rounding rule. The W3C fallback guarantees the exact integer channels shown above. Mixed-channel inputs (for example, equal cyan and magenta with no yellow or black) also resolve to predictable screen colors and are worth adding to a personal sanity check whenever you adopt a new converter.
When a Browser Preview Is Enough, and When It Is Not
The naive formula deliberately ignores everything that affects a real print job: the press profile, the ink set, the paper, the dot gain, the rendering intent, and the embedded ICC profile. Two presses running the same nominal CMYK recipe can produce visibly different paper colors, and the difference between an uncalibrated screen preview and the printed sheet is often large enough to fail brand-color checks. Real CMYK is device-dependent in a way RGB on a single monitor is not, which is exactly why professional software converts between CMYK and RGB through matched source and destination profiles.
Reach for the browser preview when the task is one of the following:
- Sketching a screen mockup from a printer-supplied swatch.
- Comparing two CMYK recipes to see how close they look on sRGB.
- Picking a print-only color for a hero image, an email accent, or a CSS gradient stop.
- Explaining to a stakeholder roughly what a CMYK recipe will look like before committing to a press proof.
Step away from the browser preview and into profile-aware software (Photoshop, Illustrator, Acrobat, InDesign) with the correct ICC profile, a calibrated display, and a physical proof when the color is contractual, brand-critical, or part of a press approval; when you need to choose between two near-identical recipes with confidence; or when the deliverable is a print-ready file rather than a screen preview.
Adobe documents this workflow in its color conversion and ink management guidance, and the W3C source for the naive formula is published in the CSS Color Module Level 4 working draft. For designers who need to make the same comparison inside Photoshop, the convert CMYK to RGB in Photoshop for accurate screen previews guide covers the profile-aware path in detail.
Browser Preview vs. ICC-Aware Conversion
The table below summarizes the practical difference between the two workflows. Use it to pick the right tool for the job rather than as a measurement of accuracy.
| Aspect | Naive browser preview | ICC-aware conversion |
|---|---|---|
| Inputs accepted | Four CMYK percentages, 0 to 100 | CMYK image or values plus source and destination profiles |
| Profile handling | None; falls back to device-CMYK | Uses embedded or assigned ICC profiles with rendering intent |
| Typical use | Screen mockups, palette checks, rough UI work | Print production, brand colors, contractual targets |
| Processing location | Local browser, no upload | Application-dependent; many send data to a color engine |
| Output | 8-bit RGB channels, hex, and swatch | Profiled RGB (or CMYK) values plus proofing report |
| Color-management requirement | None | Calibrated display, printer ICC profile, and physical proof |
If you only need to know roughly how a print recipe will appear on screen, the naive preview is faster and lighter. If you need a number you can stake a press run on, the ICC-aware workflow is the only acceptable option. The browser preview is a directional tool; the profiled conversion is a measurement tool.