sRGB

sRGB (standard RGB) is a colour space jointly developed by HP and Microsoft in 1996 and standardised by the International Electrotechnical Commission as IEC 61966-2-1. It specifies the exact red, green, and blue primaries that define how RGB numerical values map to perceived colours, plus a non-linear gamma curve approximating the response of a typical CRT monitor of the era.

sRGB is the implicit colour space of the web. When you write #FF6B35in CSS, you’re specifying a colour in sRGB. When a JPG file doesn’t embed a colour profile, sRGB is the assumed default. Browsers, image editors, and consumer monitors all default to sRGB.

Wider-gamut colour spaces — Display P3 (Apple, ~25% more colour volume than sRGB) and Rec.2020 (HDR video) — extend beyond sRGB’s triangle into deeper saturated colours that older displays can’t produce. CSS Color Module Level 4 supports both with color(display-p3 ...) and color(rec2020 ...) functions, but browser support is still uneven and most assets still ship in sRGB.

For everyday colour conversion (HEX ↔ RGB ↔ HSL), sRGB is the universal anchor. Use our colour converters for the math.

The sRGB gamma curve specifically:sRGB doesn’t use a pure power function. The transfer curve is piecewise: a linear segment for very dark values (encoded values below 0.04045 are divided by 12.92) and a 2.4-power curve above that. The composite approximates a 2.2 gamma but with better numerical behaviour near zero. This piecewise definition is the reason “just raise to the 2.2 power” produces slightly wrong colours near black — accurate sRGB linearisation needs the full curve.

White point and primary chromaticities:sRGB’s white point is D65 (CIE Illuminant D65, ~6504 K), and its three primaries sit at specific (x, y) chromaticity coordinates: red (0.640, 0.330), green (0.300, 0.600), blue (0.150, 0.060). These match the phosphor primaries of mid-1990s CRT monitors — deliberately, so existing displays would be standard-compliant without modification. Modern OLED and quantum-dot displays cover much more than the sRGB triangle, which is why wide-gamut content looks more saturated on capable hardware. Related: Display P3, gamma, chromaticity. Reference: IEC 61966-2-1 sRGB specification.

Worked example

Convert the CSS colour #FF6B35 (red orange) to linear-light sRGB for blending math. The 8-bit values are R=255, G=107, B=53. First normalise to [0,1]: (1.0, 0.4196, 0.2078). Apply the inverse sRGB transfer for each channel: R = ((1.0 + 0.055)/1.055)^2.4 = 1.0; G = ((0.4196 + 0.055)/1.055)^2.4 ≈ 0.1471; B = ((0.2078 + 0.055)/1.055)^2.4 ≈ 0.0355. Now you can alpha-blend or compute luminance correctly: Y = 0.2126·R + 0.7152·G + 0.0722·B ≈ 0.32. The naïve mistake — averaging the gamma-encoded values directly — would compute Y ≈ 0.42 and produce washed-out blends. This single subtlety is why “why does my 50% opacity overlay look wrong” is a recurring graphics-programmer question, and why GPU shaders explicitly mark textures as sRGB so the hardware linearises on read.

When and why it matters

Any time you write image-processing or rendering code, knowing whether your pixel values are gamma-encoded sRGB or linear-light determines whether blending, blurring, and lighting calculations produce the colours you expect. The same logic applies to design tools: Photoshop’s “blend RGB colors using gamma” option flips this behaviour; Figma defaults to gamma-correct (linear) blending in 2024+. For web work, sRGB is so universal that you rarely need to think about it — but the moment you ship Display-P3 content for iPhone HDR cameras or render Rec.2020 HDR video, the assumption breaks and unmanaged images shift saturation visibly. The defensive habit: tag every image with an explicit ICC profile rather than relying on the “untagged = sRGB” default, especially when sharing across mobile platforms with deep colour pipelines. Reference: W3C — CSS Color Module Level 4.