Without decimal places, HSL can only represent 360 * 100 * 100 or 3,600,000 colours, whereas 24-bit RGB represents 16,777,216 (256 ** 3). With one decimal place HSL can represent 360,000,000 colours. In W3C's CSS Color Module Level 4 candidate recommendation draft, an example RGB to HSL formula is provided which returns values with unlimited decimal places: https://www.w3.org/TR/css-color-4/#rgb-to-hsl

I believe browsers ultimately convert HSL to RGB before rendering. If you provide a HSL value, a browser will show the computed value expressed in RGB. I can't find an MDN or W3C resource that confirms this, but see e.g.:

• https://mamutlove.com/en/blog/rgb-hsl-lch-lab/#nowadays
• https://stackoverflow.com/a/39211005/4002016

Assuming this conversion does take place, I don't know whether the different colour spaces used by RGB and HSL would cause even those 360 million HSL colours to miss some of the RGB colours. In any case, going to one decimal place on saturation and lightness seems like a good start and is better than a lot of colour converters that just ignore this lossy translation issue. For example, when converting from rgb(48, 219, 231):

• Coolors, cccolor, HSL Color Picker, and W3Schools return hsl(184, 79%, 55%), which is converted to rgb(50, 219, 231) by my browser
• PineTools returns* hsl(183.9, 79%, 55%), which is also converted to rgb(50, 219, 231) by my browser
• RapidTables returns* hsl(184, 79.2%, 54.7%), which is converted perfectly by my browser
• W3C's example formula returns* hsl(183.9344262295082, 79.2207792207792%, 54.70588235294118%), which is also converted perfectly by my browser but aren't nice to look at

See also:

• https://pow.rs/blog/dont-use-hsl-for-anything

* these all return individual values rather than a CSS value, but I've represented them as CSS values here for convenience