Color Converter (HEX, RGB, HSL)
Convert colours between HEX, RGB, HSL and HSV. Paste one colour per line, including 3-digit HEX, rgb() and hsl() values, and click any swatch to copy its HEX
Convert colours between HEX, RGB, HSL and HSV in both directions. Paste one colour per line - including 3-digit shorthand HEX, rgb() and hsl() values - and get every representation at once, with a swatch you can click to copy the HEX code.
Useful when a design tool gives you HSL but the CSS you inherited uses HEX, when you need the RGB triplet for a canvas or an Android resource file, or when you are checking a brand palette and want to see how the shades relate. The conversion follows the standard CSS formulas, and alpha values are preserved when you supply them.
How to convert colours between HEX, RGB, HSL and HSV
Enter one colour per line in any supported format
Read the converted HEX, RGB, HSL and HSV values
Click a swatch to copy its HEX code
FAQ
Which formats are accepted as input?
HEX (#1a2b3c or #abc), rgb(26, 43, 60), rgba(...), hsl(210, 40%, 17%) and hsla(...), one per line, with or without the function name in lowercase.
Can I convert several colours at once?
Yes, paste a whole palette - one colour per line - and every line is converted independently.
How do I copy a result?
Click any colour swatch and its HEX value is copied to the clipboard; the text output can also be selected and copied like any other text.
Is the result identical to CSS colour functions?
Yes, the standard sRGB formulas are used, and HSL/HSV values are rounded for readability. Rounding can shift a channel by one unit, which is invisible in practice.
Does it handle transparency?
Alpha values in rgba() and hsla() input are preserved in the HEX output as an 8-digit value with alpha.
Is anything sent to a server?
No, the conversion is pure arithmetic performed in your browser.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.