Hex to RGB Calculator

Understanding the Hex to RGB Calculator

A hex to RGB converter splits a six-digit colour code into three channel values from 0 to 255. Each pair of hex digits is one byte, which is why the notation exists: it writes three bytes in six readable characters with no arithmetic required.

How it actually works

Enter a hex colour with or without the leading hash. The calculator expands three-digit shorthand, then reads each pair as a base-16 number. The value 3B82F6 gives red 59, green 130, and blue 246.

The deeper context most people miss

Two hex digits cover exactly 0 to 255 because 16 squared is 256, which is why a byte maps to two hex digits with nothing wasted. The three-digit shorthand doubles each digit, so it can only express colours where both digits of each pair match, giving 4,096 of the 16.7 million possible values.

Why 8 bits per channel and what it misses

Eight bits per channel gives 256 levels each and about 16.7 million combinations, which was chosen because it fits a byte and because it exceeds what the eye distinguishes for most purposes. It does not exceed it everywhere. Smooth gradients across a large area can show visible banding, where the step between adjacent levels becomes perceptible as a stripe, and this is most noticeable in dark regions and in subtle sky or shadow gradients. The reason is that human brightness perception is roughly logarithmic, so equal numeric steps are not equal perceptual steps, and the darkest levels are spread further apart perceptually than the brightest. Dithering hides banding by adding structured noise. Higher bit depths address it directly, with 10 or 12 bits per channel used in professional video, medical imaging, and high dynamic range formats, and the difference is genuinely visible on gradients. A related and frequently missed point is that the numbers in a hex code are not linear light values. Standard sRGB applies a transfer function, roughly a power of 2.2, so a value of 128 emits considerably less than half the light of 255. This is why averaging two colours by averaging their channel values gives a result darker than it should be, and why correct blending, resizing, and antialiasing convert to linear light first, which many implementations historically did not.

A worked example: why gradients and blends look wrong

The colour 3B82F6 has channels 59, 130, and 246, and blending it with white by averaging each channel gives 157, 192, 250. Done in linear light rather than in the encoded values, the correct blend is noticeably brighter. This affects more than deliberate blending: image resizing averages neighbouring pixels, antialiasing blends edge pixels with the background, and alpha compositing mixes layers, and all of them are averaging operations. Performing them on gamma-encoded values, which was standard practice for years, produces results that are systematically too dark, most visibly on thin light-on-dark text which appears thinner and dimmer than it should. Converting to linear light, averaging, and converting back fixes it, and modern graphics pipelines and CSS colour interpolation increasingly do this correctly. The same issue explains why a checkerboard of black and white pixels viewed from a distance looks darker than mid-grey 128 and closer to 187, which is the sRGB encoding of half the light. Understanding that the numbers encode perceptual steps rather than physical light quantities resolves a whole family of otherwise mysterious rendering artefacts.

Deciding which colour notation to use

Hex is compact and ubiquitous in web and design tools, and it is poor for reasoning about colour since adjusting a hue means changing all three channels in a way that is not obvious. RGB in decimal is the same information in a more arithmetic-friendly form. HSL and HSB express hue, saturation, and lightness or brightness, which makes adjustments intuitive: shifting hue rotates through the spectrum, and reducing saturation moves toward grey, both being single-parameter changes that hex cannot express directly. That makes HSL the better choice when generating palettes programmatically or building a theme, and it has a flaw worth knowing: its lightness is not perceptual, so two colours with the same HSL lightness can look markedly different in brightness, with yellow appearing much lighter than blue at identical lightness values. Perceptually uniform spaces including CIELAB, and the newer OKLCH now supported in CSS, fix this, with equal numeric changes corresponding to roughly equal perceived changes, which makes them substantially better for generating accessible palettes and smooth gradients. For accessibility work specifically, contrast ratio calculations use relative luminance computed from linearised channel values, which is why a contrast checker cannot work from hex digits directly.

Colour spaces, gamut, and why the same hex looks different

A hex code is meaningless without knowing which colour space it refers to. The same triple of numbers describes different physical colours in sRGB, Display P3, and Adobe RGB, because each space defines its primaries differently, so the maximum red in a wider gamut is a more saturated red than in sRGB. Untagged content is conventionally assumed to be sRGB, which is why images without an embedded profile look approximately right and why images tagged with a wide gamut profile look oversaturated when a viewer ignores the tag. Modern displays increasingly cover more than sRGB, and CSS now supports specifying colours in Display P3 and other spaces explicitly, which means a colour outside sRGB can be requested and will be displayed on capable hardware. Print introduces a further problem, since CMYK inks cannot reproduce many saturated screen colours at all, so a vivid blue chosen on screen has no print equivalent and must be substituted or printed as a spot colour. Colour management exists to handle all of this, mapping between spaces through a device-independent reference using profiles and a rendering intent. For anyone specifying brand colours, giving values in each relevant space explicitly rather than converting a single hex value is what produces consistent results across media.

Variations: notation forms and alpha

Six-digit hex encodes three channels. Three-digit shorthand doubles each digit and covers only 4,096 colours. Eight-digit hex adds an alpha channel as a fourth pair, and four-digit shorthand does the same, though support has varied and the ordering convention differs in some contexts with alpha sometimes leading. Functional notation in CSS accepts rgb with decimal or percentage values, and modern syntax allows a slash-separated alpha. HSL and HWB express colour differently. LCH and OKLCH provide perceptually uniform alternatives now supported in browsers. Named colours cover a fixed list with some historically inconsistent definitions. In other contexts, some systems use BGR ordering rather than RGB, which is a classic source of red and blue appearing swapped, and some image formats and APIs order alpha first. Bit depth varies from 8 to 16 per channel. Indexed colour uses a palette. For any conversion, checking channel order and whether values are premultiplied by alpha avoids the most common bugs, since premultiplied and straight alpha are both in use and mixing them produces dark or bright fringes at edges.

Working with hex colours

Read each pair of digits as one byte from 0 to 255, since two hex digits cover exactly that range and the mapping is why the notation exists. Expand three-digit shorthand by doubling each digit, remembering it can only express 4,096 of the 16.7 million possible colours. Convert to linear light before averaging, blending, or resizing, since the encoded values are not proportional to light and averaging them directly produces results that are too dark. Use HSL or HSB when adjusting colours by hand, since hue and saturation are single-parameter changes that hex cannot express. Prefer OKLCH or a perceptually uniform space when generating palettes or gradients, since HSL lightness is not perceptual and yellow looks far lighter than blue at the same value. Compute contrast ratios from linearised luminance rather than from the hex digits, which is why accessibility checkers do their own conversion. Specify which colour space a hex value refers to when it matters, since the same digits describe different colours in sRGB and Display P3. And check channel order when interfacing with libraries, since BGR ordering is common.

What people get wrong

• Averaging hex channel values to blend two colours, when the encoding is not proportional to light and the result comes out systematically too dark.
• Treating HSL lightness as perceptual brightness, when yellow and blue at identical lightness values look markedly different and palettes built on it appear uneven.
• Assuming a hex code specifies a colour absolutely, when the same digits describe different colours in sRGB, Display P3, and Adobe RGB.
• Expecting three-digit shorthand to express any colour, when doubling each digit reaches only 4,096 of the 16.7 million eight-bit combinations.

Where the math comes from

Each pair of hex digits is a base-16 number from 00 to FF, giving 0 to 255, because 16² equals 256 and two hex digits therefore encode exactly one byte. Three-digit shorthand expands by doubling each digit, so 3B8 becomes 33BB88. The three channels give 256³, about 16.7 million, distinct colours.

Questions and answers

Related calculators

Modular Arithmetic · Sphere · Standard Deviation · Derivative at Point · Complex Number