Convert HSL to RGB

HSL to RGB Color Converter

Most rendering pipelines expect RGB, not HSL.

When a canvas context, a WebGL shader, or a server-side image library asks for numeric color channels, you need to decompose your hsl() values into the red, green, and blue integers those APIs understand. The conversion is deterministic and lossless for standard HSL inputs: any well-formed hsl() value maps to exactly one rgb() triple, with no ambiguity about which color it represents across platforms.

How the conversion works

Inside the HSL model, hue is a 0–360 degree angle, saturation a 0–1 ratio, and lightness a 0–1 ratio. The conversion derives three intermediate chroma values from saturation and lightness, then maps each onto the correct sextant of the hue wheel (such as the 0–60° and 60–120° ranges) to produce the red, green, and blue channels.¹ Consequently, hues at sextant boundaries (0°, 60°, 120°, 180°, 240°, 300°) produce cleaner integer RGB values, while intermediate hues accumulate sub-integer remainders that the final Math.round() step resolves.

Why the sextant model matters

Each 60-degree sector of the hue wheel assigns a different channel as the maximum and a different formula for the remaining two channels. The red channel dominates the first sector (0° to 60°), green dominates the second (60° to 120°), and blue takes the third. This rotating assignment repeats for the second half of the wheel. Understanding which sector your hue falls in tells you which RGB channel will be the largest after conversion, which helps when debugging unexpected color shifts.

The sextant logic also explains why neighboring hues shift only one channel at a time. In the first sector red peaks while blue holds at zero, so a small hue change moves mostly between red and green as you cross into the next sector. That behavior is why converting a hue near a boundary can change two channels instead of one, and why designers sometimes nudge a hue back inside a sector to keep a single-channel gradient.

Where this comes up

Three workflows drive most HSL-to-RGB conversions. Design systems that define palette tokens as hsl() variables need RGB output to export values to platforms that only accept hex or numeric channels. WebGL fragment shaders require float triplets in 0–1 space, which means dividing each 0–255 RGB channel by 255 after conversion. Furthermore, server-side renderers (Node.js sharp, ImageMagick, or Cairo-based SVG exporters) parse colors from rgb() or hex strings and reject hsl() syntax entirely, making the conversion a required step before any server-side image operation.

Server-side rendering constraints

Any environment that processes images outside the browser typically lacks native HSL support. Node.js canvas implementations, Rust image crates, and Python imaging libraries all expect colors in RGB or hex format. When your design tokens live in HSL because they were authored for a CSS-in-JS system, you must convert them before the server-side code can use them. This is especially common in static site generators that produce social media preview images at build time.

Edge cases and rounding

Achromatic inputs (saturation 0) produce equal red, green, and blue channels regardless of the hue angle, which becomes irrelevant and is ignored. Hue values outside 0–360 wrap modulo 360: 390° and 30° produce identical output.¹ Saturation or lightness above 1.0 are undefined; clamp them before conversion. Because RGB requires integer channels and the conversion intermediate is floating-point, each channel rounds at the final step. Yet rounding means a round-trip of HSL → RGB → HSL may shift the hue or saturation by a fraction of a percent, which is perceptually invisible but measurable in exact comparisons.

When achromatic output catches you off guard

If you convert an HSL color with saturation near zero, the hue angle has almost no effect on the RGB output. This can produce unexpected results when you expect a warm grey (based on a hue near 30°) but get a neutral grey because the saturation value was 0.1% instead of 1%. Always verify the saturation value before relying on hue to influence the output in low-saturation regions of the HSL space.

HSL to RGB for server-side image generation

Server-side image generation tools (Node.js sharp, Python Pillow, ImageMagick) accept RGB values but not HSL, so you need to feed an hsl() color to a server-side renderer in the format it accepts. When your design system stores colors as HSL tokens and your server-side code needs to generate images (social media cards, email headers, PDF covers), you must convert HSL to RGB before passing the values to the image library. The conversion is the same algorithm as the client-side version, but the implementation details differ across languages.

In Python, the colorsys module provides hls_to_rgb() (note: HLS, not HSL, with the L and S channels in a different order).² In Node.js, packages like color-convert provide hsl.rgb(h, s, l) which returns [r, g, b] as 0–255 integers. Building on this, always verify the channel order and range expected by your specific library. Some libraries expect 0–1 floats, others expect 0–255 integers, and a few use 0–100 percentages. Passing the wrong range produces silently wrong colors that are hard to debug because the code runs without errors.

HSL to RGB in WebGL shader uniforms

WebGL shaders require colors as vec3 or vec4 float triplets/quadruplets in 0.0-1.0 space.³ Converting HSL to RGB for a WebGL uniform is a two-step process: first convert HSL to 0–255 RGB integers, then divide each by 255.0 to get the float triplet. Some developers implement the HSL-to-RGB conversion directly in GLSL to avoid the CPU-side conversion, but the GLSL implementation is more complex and slower than doing the conversion once on the CPU and passing the result as a uniform.

The GLSL implementation requires replicating the hue-sextant logic (six 60-degree sectors with different channel assignments) using step() and mix() functions. This is useful when you need to convert HSL to RGB per-fragment for a color picker visualization, but for static colors, the CPU-side conversion is simpler and faster. Building on this, if your application dynamically adjusts HSL values (for example, a color picker UI), do the conversion in JavaScript on the CPU and update the uniform, rather than implementing the conversion in the shader.

Precision considerations for HSL-to-RGB in design systems

Design systems that store colors as HSL and convert to RGB at build time need to decide how many decimal places to preserve in the HSL coordinates. Storing hue as an integer (217) and saturation/lightness as integers (91%, 60%) is sufficient for most use cases. Storing additional decimal places (217.3, 91.2%, 59.8%) provides marginally better precision but increases token file size and provides no visible benefit for 8-bit display output.

The practical limit is the 0–255 integer RGB output: any HSL precision beyond what affects the rounded RGB value is wasted. For a hue angle, this means roughly one decimal place is the useful maximum. For saturation and lightness percentages, one decimal place is also sufficient. Building on this, if your design system uses OKLCH as the canonical format and converts to HSL as an intermediate step, the additional conversion step may introduce rounding that would not exist if you converted directly from OKLCH to RGB. Minimize conversion steps in your token pipeline to preserve precision.

When to use this

Use this when a design token or CSS variable defined in HSL needs to be passed to a canvas API, a WebGL shader, or a server-side renderer that only accepts numeric RGB channels.

Examples

hsl(74, 100%, 50%)

rgb(200, 255, 0)

hsl(217, 91%, 30%)

rgb(6, 71, 153)