HSL to CSS string formatter

The formatter validates every component, normalizes the hue around the color circle, rounds values to a chosen precision, and returns one predictable string. It is useful anywhere structured color data must become browser-ready CSS, from design-token pipelines and theme generators to automated tests, templates, and small developer utilities.

Supply numeric HSL components

Provide hue, saturation, and lightness as JSON numbers, not as a partly formatted CSS expression. Hue represents an angle in degrees and may be positive, negative, or greater than one full turn. The formatter wraps it into the canonical interval beginning at zero and ending just before 360, so -30 becomes the same color angle as 330 and 390 becomes 30. Saturation and lightness represent percentages, but their inputs do not include percent signs: use 65 for sixty-five percent. Both must remain between 0 and 100 inclusive because values beyond those limits do not describe a valid percentage component for this contract. Every required value must be a finite number. Strings such as "50", missing fields, null, Infinity, and NaN are rejected instead of being silently coerced. This strict boundary makes data errors visible early and keeps output identical across API calls, browser widgets, build scripts, and test fixtures.

Control deterministic rounding

Use precision to select the maximum number of decimal places retained for all three components. It defaults to two and accepts integers from zero through six. A precision of zero produces whole components, while higher values preserve more detail when a color came from calculation or conversion. Rounding happens only after hue normalization, which prevents a negative or multi-turn hue from leaking into the formatted result. The formatter removes unnecessary trailing zeroes, so a value rounded to 42.50 is written as 42. It also canonicalizes negative zero as plain zero, avoiding surprising strings such as -0% after rounding a very small value. These rules are deliberately fixed rather than locale-aware: decimal points always use a period, argument separators are always commas followed by spaces, and saturation and lightness always receive percent signs. Consequently, the same valid input and precision always return byte-for-byte identical CSS regardless of regional settings or runtime environment.

Use the returned CSS safely

The result contains a css field whose value follows the familiar hsl(h, s%, l%) functional notation. You can place that value in a stylesheet declaration, assign it through a DOM style property, store it as a design token, or compare it directly in a golden test. The capability formats a color; it does not convert RGB or hexadecimal input, apply alpha transparency, calculate contrast, or decide whether a color is suitable for text. Keeping that scope narrow makes validation and output easy to reason about. When generating many theme values, validate upstream records and call the formatter once per color so each failure points to a specific item. If precision is part of a public design-token convention, pass it explicitly rather than relying on the default. For API automation, each request is priced at $0.002; the same pure algorithm can also power the browser experience. Treat the returned string as generated data and place it only where a CSS color value is expected, rather than interpolating it into unrelated markup or selectors.