A designer hands you a mockup where every color is a hex code — #3B82F6 for primary, #1E3A5F for deep navy, something labeled "just a slightly lighter blue" that you realize later is #60A5FA. Your CSS file wants these as RGB triples. Your design tokens are defined in HSL so the dark-mode variant can adjust lightness systematically. Your iOS engineer needs them as sRGB decimals. Your print vendor is going to ask for CMYK. And every one of those formats represents the same color in a different mathematical language.
The modern web runs on roughly five color models you actually need to convert between. HEX (#RRGGBB) is the most compact and every developer has typed it. RGB (three integers 0–255) is what every low-level API and most browser DevTools expect. HSL (hue 0–360, saturation 0–100, lightness 0–100) is how designers think — it lets you say "make this 20% lighter" without accidentally shifting the hue. CMYK (cyan/magenta/yellow/key 0–100 each) is the subtractive space ink lives in, and the reason your vibrant on-screen orange prints as a muddy rust. And OKLCH is the newer perceptually-modern alternative to HSL that's starting to show up in design tools because it doesn't have HSL's well-known saturation-grayness-bug in the blues.
This tool is a two-way translator between all of them. Type a hex code and you instantly get HSL, RGB, CMYK, and OKLCH values, plus a live swatch preview showing what the color actually looks like. Type into any output field and the others recalculate — it's bidirectional, so editing the saturation number updates the hex code and the RGB values in lockstep. The hue slider spins through all 360 degrees; the lightness and saturation sliders cover their full ranges with a gradient preview that shows where on the scale you are.
The CMYK conversion deserves a small warning: every RGB→CMYK formula is an approximation, because the two color spaces (additive light vs. subtractive ink) have genuinely different gamuts. Some RGB colors — electric greens, certain oranges, neons — have no CMYK equivalent at all. The tool flags these gamut mismatches so you know to expect a print shift rather than being surprised by a swatch that looked right on screen.
A couple of real translation pitfalls this saves you from. The RGB→HSL formula is piecewise and has a well-known undefined-hue case for pure gray values (R=G=B). A bad implementation returns a random hue for gray; this one correctly reports "undefined." Hex codes with alpha channels (#3B82F680) need exactly the right byte order or you produce a different transparency value than you intended. And WCAG contrast ratios computed from HSL lightness are approximate; the tool computes them from the linearized RGB values instead, which is the technically-correct path and rarely matches the "just adjust lightness" guess you'd make by hand.
Where this shows up in practice: a design-system audit where you're converting a flat HEX color palette into an HSL-based token architecture for dark mode, confirming that a designer's "slightly different blue" is actually distinguishable from the existing palette (it often isn't), generating the CMYK equivalents of a brand palette for a print vendor without paying for an Illustrator seat, building a quick contrast-and-accessibility check between two color values during a code review, writing a color-manipulation utility in code and verifying the round-trip HSL → RGB → HSL produces the original values for grays, and producing "CSS variable / SCSS / Tailwind / Swift / Flutter" snippets from a single source-of-truth color in a style guide handoff.