颜色转换器 — HEX、RGB、HSL 与 OKLCH

什么是颜色转换器?

// sRGB → linear → XYZ D65 → OKLAB → OKLCH
// References: W3C CSS Color 4 §11-15, Ottosson 2020 (https://bottosson.github.io/posts/oklab/)
// Worked example: #3b82f6 (Tailwind blue-500)

const srgb = [0x3b, 0x82, 0xf6].map(v => v / 255); // [0.231, 0.510, 0.965]

const toLinear = (v) => v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
const lin = srgb.map(toLinear); // gamma-decoded linear-sRGB

// linear-sRGB → XYZ D65 (CSS Color 4 §15.1 matrix)
const [lr, lg, lb] = lin;
const x = 0.4124564 * lr + 0.3575761 * lg + 0.1804375 * lb;
const y = 0.2126729 * lr + 0.7151522 * lg + 0.0721750 * lb;
const z = 0.0193339 * lr + 0.1191920 * lg + 0.9503041 * lb;

// XYZ D65 → LMS (Ottosson 2020 matrix), cube-root, → OKLAB
const l_ = Math.cbrt(0.8189330101 * x + 0.3618667424 * y - 0.1288597137 * z);
const m_ = Math.cbrt(0.0329845436 * x + 0.9293118715 * y + 0.0361456387 * z);
const s_ = Math.cbrt(0.0482003018 * x + 0.2643662691 * y + 0.6338517070 * z);
const L = 0.2104542553 * l_ + 0.7936177850 * m_ - 0.0040720468 * s_;
const a = 1.9779984951 * l_ - 2.4285922050 * m_ + 0.4505937099 * s_;
const b = 0.0259040371 * l_ + 0.7827717662 * m_ - 0.8086757660 * s_;

// OKLAB → OKLCH (Cartesian to polar)
const C = Math.sqrt(a * a + b * b);
const H = (Math.atan2(b, a) * 180 / Math.PI + 360) % 360;
console.log(`oklch(${L.toFixed(3)} ${C.toFixed(3)} ${H.toFixed(1)})`);
// → oklch(0.629 0.193 263.4)

核心特性

颜色转换器替代品对比

颜色转换示例

#3b82f6

#FF5733

#FF6347

oklch(0.7 0.25 30)

#767676

#FF6347

hsl(220 70% 50%)

#3b82f6

如何使用颜色转换器

1. 1

   用任意格式粘贴或键入颜色

   全部 9 个格式字段(HEX、RGB、HSL、HSV、HWB、CMYK、OKLCH、OKLAB、Named)都可以直接编辑 —— 没有需要点击的「转换」按钮。从 Figma 粘贴 hex、从 Tailwind 配置中键入 oklch() 值、把旧样式表里的 hsl() 丢进来,甚至键入像 tomato 这样的 CSS 命名颜色都行。工具会随键入逐步解析,所以一个写到一半的值不会在您提交合法格式之前抹掉其他字段。非法输入会在行内静默提示错误;合法输入则会刷新整个网格。

2. 2

   9 种格式即时同步

   内部的事实源是 OKLCH(感知均匀、色域无界),其他每一种格式都在每次按键时由它派生。您正在键入的那个字段保持光标位置不动 —— 只有*其他*八个字段重新渲染。这意味着您可以直接编辑 OKLCH 的 L 通道,实时看到 hex、RGB、HSL、CMYK 全部跟着变,而不会丢失光标。转换数学完全在 JavaScript 中运行,使用与现代浏览器内置一致的 OKLAB 原语。

3. 3

   用取色器做可视化探索

   格式网格下方是一个饱和度-亮度方块(在当前色相下,拖动任意位置设置 S+L)、一个色相滑块(拖动可绕色轮旋转)和一个 alpha 滑块(拖动设置透明度)。在 Chromium 系浏览器(Chrome、Edge、Brave)上,Eyedropper 按钮会激活原生 EyeDropper API —— 在屏幕任意位置点击(包括浏览器窗口之外)以取样该像素的颜色。Safari 和 Firefox 尚未提供该 API,因此按钮在这些浏览器中会隐藏,SL 方块 + 色相滑块仍然是主要的取色器。

4. 4

   一眼掌握色域与对比度

   三枚色域徽章(sRGB、Display P3、Rec2020)会显示当前颜色是否落在每个空间的可再现范围内 —— 在您用 OKLCH 工作、想知道哪些显示器能准确渲染该值时非常有用。对比度行会显示对白与对黑的 WCAG 2.1 比率,以及 APCA Lc 分数(前瞻性的 WCAG 3 指标)。通过 / 未通过徽章(AA、AAA)会行内显示。如果颜色超出 sRGB 色域,Snap to sRGB 按钮会缩减 chroma 直到合身。

5. 5

   用您所在平台的原生语法复制

   9 个格式字段各自都有自己的复制按钮 —— 一键即可把值送到剪贴板,标签短暂切换为「Copied!」以便您知道。取色器下方的复制为代码区段会为五个平台生成可粘贴的代码片段:CSS 自定义属性、Tailwind v4 @theme token、SwiftUI Color(red:green:blue:) 字面量、Jetpack Compose Color(0xFF...) 常量,以及 Flutter Color(0xFF...)。URL 哈希(#hex=... 或 #oklch=...)也会同步更新,这样您就能分享一条实时链接,指向那一确切的颜色。

颜色转换常见错误

假设 HSL 调色板感知均匀:
hsl(220 50% 30%) → hsl(220 50% 60%) → hsl(220 50% 90%)
屏幕上这几个值看上去间距不均。

使用 OKLCH 做感知均匀的色阶:
oklch(0.30 0.10 220) → oklch(0.60 0.10 220) → oklch(0.90 0.10 220)
屏幕上这几个值看上去间距均匀。

把我们的 CMYK 输出直接发去印刷:
hex #FF6347 → cmyk(0%, 61%, 72%, 0%)
印出来可能浑浊或过饱和。

把原始 hex 发给印刷供应商:
hex #FF6347 → 让印刷厂针对其印刷机做 ICC 转换
印出来与屏幕颜色匹配得多。

假装 Lc 60 = WCAG 4.5:1:
APCA Lc 60 → 「通过 AA」
同一对组合的 WCAG 2 比率可能是 3.8:1(不过 AA)。

独立检查两个指标:
WCAG 2 比率 ≥ 4.5:1 满足 AA 正文文本合规,且
APCA |Lc| ≥ 75 满足现实可读性。
两者都必须通过,不能用一个替代另一个。

对 HSL L 做色阶递增:
hsl(220 50% 30%) / hsl(220 50% 60%) / hsl(220 50% 90%)
90% 看上去发白;30% 比 60% 的间距看上去暗得多。

对 OKLCH L 做色阶递增:
oklch(0.30 0.10 220) / oklch(0.60 0.10 220) / oklch(0.90 0.10 220)
每一步看起来都是相同的视觉间距。

把 8 位 hex 复制到老旧解析器:
#FF573380 → 解析器截断 → #FF5733(无 alpha)
50% 的透明度被静默丢失。

核验目标支持 8 位 hex,或使用 rgba():
现代 CSS:#FF573380(8 位 hex)
旧版兼容:rgba(255, 87, 51, 0.5)(始终支持)
显式 alpha 语法避免静默截断。

默认把每个 OKLCH 颜色 snap 到 sRGB:
oklch(0.7 0.25 30) → snap → oklch(0.7 0.18 30)
P3 显示器无端损失 30%+ 饱和度。

先看 Display P3 徽章:
若落在 P3 内:保留广色域值,通过 @supports 加 sRGB 回退
若超出 P3:再 snap 到 sRGB
让广色域硬件干它该干的活。

谁在使用这款工具

前端开发者迁移到 Tailwind v4 OKLCH token

Tailwind v4 在 2024 年把默认调色板标准化到了 OKLCH。把基于 HSL 或 hex 的旧设计系统迁移过来意味着要把数百个品牌色转成 OKLCH。粘贴每一个 hex,复制 OKLCH 输出,丢进 @theme 块里。实时色域徽章会标出任何超出 sRGB 的颜色,让您能决定是否为 Display P3 显示器保留更广色域的值。

设计师把 Figma 颜色翻译给 iOS / Android

Figma 默认导出 hex,而 iOS 想要 SwiftUI Color(red:green:blue:) 字面量,Android 想要 Jetpack Compose Color(0xFF...) 常量。Figma hex 粘贴一次,复制 SwiftUI 片段给 iOS 工程师、Compose 片段给 Android 工程师 —— 两者都已经是各平台所需的精确语法,原 hex 保留在注释里以便追溯。

设计师准备印刷打样(CMYK 近似)

当一种品牌色必须出现在印刷名片上时,CMYK 近似值可以给印刷厂在做正式 ICC 转换前共享一个快速估算。粘贴品牌 hex,复制 CMYK 百分比,发给印刷厂获取一份快速报价 —— 然后把最终颜色匹配交给印刷厂自己针对具体印刷机做的 ICC 配置文件感知的转换。

无障碍工程师核验 WCAG 和 APCA

WCAG 2.1 是当下的监管标准(ADA、EAA、Section 508);APCA Lc 是拟议中的 WCAG 3 继任者。两个指标并排显示意味着设计师可以在一屏内验证一个正文文本颜色对白色达到 4.5:1 的 WCAG,然后再做 sanity check 看是否也通过 APCA Lc 75 —— 无需在两个独立计算器之间来回切换。

教育者讲解色彩空间概念

同时显示 9 个字段的视图让色彩空间关系一目了然。键入一个 OKLCH 值,看 HSL 漂移,因为 L 在不同空间里含义不同。拖动色相滑块,看 hex、RGB、CMYK 全部更新。把 chroma 推到 sRGB 之外,看色域徽章变红。这款工具本身就是大学图形学或 HCI 课程的现成课堂演示。

品牌经理找出最接近的 CSS 命名颜色

当营销文案说「番茄色点缀」而实际品牌 hex 是 #FF6347 时,Named 字段会返回 tomato (exact),因为在 CSS 规范里 tomato 就是这个值。对于相近的 hex,该字段会用 OKLAB 中的 ΔE 距离返回最接近的命名颜色 —— 对文档、文案、口语化的颜色命名很有用。

Web 开发者把遗留 HEX 调色板转为 OKLCH

老旧站点可能在 CSS 自定义属性中用 hex 代码定义了 50 种颜色的品牌调色板。现代化到 OKLCH 让品牌团队可以用感知均匀空间表达相同的色阶。粘贴每个 hex,复制 OKLCH 输出,替换到变量定义中。下方的 Tints/Shades 面板能在交付前核验得到的色阶视觉均匀。

开源维护者编写设计 token 文档

设计 token 文档通常需要用多种语法展示同一种颜色 —— CSS 代码块用 hex、规范表用 OKLCH、文案部分用命名颜色。同时显示字段的视图让维护者一次复制全部,而不必跑三次单独的转换。可共享的 URL 哈希还让贡献者能在 GitHub issue 中链接到所讨论的精确颜色。

颜色转换的数学与算法

OKLCH 作为内部单一事实源

工具在内部把规范颜色值以 OKLCH 三元组形式持有。每个可编辑字段在每次按键时从这个三元组派生显示值;每次用户编辑先更新三元组,再触发其他八个字段的重渲染。这消除了把 HSL 或 sRGB 当作枢轴的转换器在每一步都会累积的浮点漂移。选择 OKLCH 而不是 OKLAB 是有意为之 —— 极坐标形式把色相保留为稳定的轴,因此拖动色相滑块不会意外地穿过灰色淡入淡出。按照 Björn Ottosson 2020 年的论文,OKLAB 的感知均匀性是把它视作现代颜色数学通用语的最有力理由。

矩阵来源(W3C CSS Color 4 + Ottosson 2020)

代码库中的每一个转换矩阵都标注到了原始来源。sRGB ↔ 线性 sRGB 的分段 gamma 函数来自 W3C CSS Color 4 §11.2(v <= 0.04045 ? v/12.92 : ((v+0.055)/1.055)^2.4)。线性 sRGB ↔ CIE XYZ D65 的 3×3 矩阵来自 CSS Color 4 §15.1。XYZ D65 ↔ LMS 矩阵和 OKLAB 的立方根步骤来自 Ottosson 在 https://bottosson.github.io/posts/oklab/ 发布的参考实现,完全照搬。没有矩阵被重新计算或重新推导 —— 原样复制能保证输出与规范的参考向量完全一致。

朴素 CMYK 公式与 ICC 注意事项

我们的 CMYK 输出采用标准教科书公式:K = 1 - max(R, G, B); C = (1-R-K)/(1-K); M = (1-G-K)/(1-K); Y = (1-B-K)/(1-K),作用在归一化的 sRGB 值上。这是有意为之的近似。真正的印刷准确度需要针对具体印刷机、油墨(如 US Web Coated SWOP v2、Fogra39、Japan Color 2011)和纸张的 ICC 配置文件转换,可能让通道偏移 5–15%。我们带可见的免责声明显示 CMYK 字段,以免用户把我们的值直接送进印刷机。请把输出当作报价用的 sanity check,不是交付物。

通过通道范围检查实现的色域检测

一个颜色被认定落在目标空间(sRGB、Display P3、Rec2020)的色域内,当其转换到该空间的原色后每个通道都落在 [-ε, 1 + ε] 区间内,其中 ε = 1e-7 用于吸收边界附近的浮点精度噪声。任一通道超出范围时,对应空间的色域徽章会变红。这能捕获常见情况 —— 像 oklch(0.7 0.4 30) 这样的广色域 OKLCH 颜色会被判为超出 sRGB 但在 P3 内,告诉您哪些显示器能准确渲染。检查在每次按键时运行。

Chroma 缩减 Snap 算法

Snap to sRGB 在 chroma 轴上做二分:固定当前的 L 和 H,在 C ∈ [0, currentC] 中搜索最大的 C,使其 sRGB 转换保持在色域内。搜索最多运行 30 次迭代(精度约 10⁻⁹),足以达到视觉上的精确。这与 CSS Color 4 §13 中描述的信息性色域映射算法一致 —— 保留亮度和色相、只缩减 chroma,可以让 snap 后的颜色仍可辨认地属于同一色相系。我们不直接裁剪 RGB 通道,因为那样会明显扭曲色相(尤其是蓝色)。

Brettel + Machado CVD 矩阵

色盲模拟使用两套已发表的矩阵家族。三种二色觉 —— 红色盲、绿色盲、蓝色盲 —— 使用 Brettel-Viénot-Mollon 1997 矩阵,在线性 RGB 上运算(先 gamma 解码、应用矩阵、再 gamma 编码回)。三种异常三色觉 —— 红色弱、绿色弱、蓝色弱 —— 使用 Machado-Oliveira-Fernandes 2009 矩阵,在严重度 0.66 下运算,对应一名典型的异常三色觉患者。全色盲与部分色弱使用 rec601 亮度权重(0.299R + 0.587G + 0.114B)做灰度投影。所有 8 种模拟在每次颜色变更时都会渲染。

WCAG 2 vs APCA:何时该用哪个

WCAG 2.x(当下标准)从相对亮度计算对称对比度比率:(L1 + 0.05) / (L2 + 0.05),正文文本目标 4.5:1,AAA 目标 7:1。它是 2026 年无障碍审计的法律合规下限。APCA(Accessible Perceptual Contrast Algorithm)是拟议中的 WCAG 3 继任者 —— 对极性敏感(亮底深字与深底亮字得分不同)、更贴合人类感知的可读性,正文文本目标 |Lc| ≥ 75。两者并排显示,让设计师同时达到合规的 WCAG 2 和现实可读性的 APCA,无需在两个独立计算器之间切换。

颜色转换的最佳实践

新设计系统优先 OKLCH,遗留系统保留 HEX

对任何在 2025 年或以后交付的新设计系统,用 OKLCH 定义品牌色与调色板色阶。L 轴自动得到感知均匀的色阶;chroma 轴可以表达 hex 无法编码的广色域颜色。可以通过 @supports not (color: oklch(0 0 0)) 或构建期 PostCSS 为老旧浏览器保留 hex 回退,但请把 OKLCH 设为 token 仓库里的规范值。已经有数千个 hex 变量的遗留系统可以保留 hex,直到有计划的迁移 —— 不要为变而变。

把 CMYK 输出视作近似,并与印刷供应商确认

本工具呈现的 CMYK 数字来自基于 sRGB 的朴素公式,不是 ICC 配置文件转换。把它们用于粗略报价和内部对比稿。在任何真正的印刷之前,请把原始 hex(不是 CMYK 近似)发给印刷供应商,让他们针对具体印刷机、油墨、纸张运行自己的 ICC 转换。正规转换带来的 5–15% 通道偏移很可能把一个鲜艳的红色变成浑浊的橙色,如果近似值被直接交付出去的话。

用 APCA Lc 做前瞻性的无障碍工作

WCAG 2.x 在未来数年内仍将是监管下限,但 APCA 是标准发展的方向。对新设计,在 WCAG 2.1 下限的基础上,正文文本同时命中 |Lc| ≥ 75,大字号文本命中 |Lc| ≥ 60。APCA 能捕获 WCAG 2 对称比率会漏掉的可读性问题 —— 尤其是亮背景上的细笔画文字,WCAG 比率看起来没问题,但文字在正常阅读距离上实际会消失。

让广色域颜色过一遍 Display P3 色域检查

如果您在瞄准现代 Apple 硬件(2017 年以后的 iPhone、iPad、MacBook),或交付 HDR 感知内容,请用 OKLCH 定义品牌色,并用 Display P3 徽章核验它们即便超出 sRGB 也落在 P3 内。更广色域的颜色在 P3 显示器上明显更饱和,在仅 sRGB 屏幕上则通过浏览器自带的 chroma 压缩优雅退化。除非您确定整个受众都在使用老旧显示器,否则不要预先把颜色 snap 到 sRGB。

用 OKLCH Tones 挑选感知均匀的色阶

为品牌色生成 50/100/200/…/900 色阶时,使用 Tones 面板:它在保持 C 与 H 不变的前提下对 L 做等步长递增。结果是感知均匀的色阶,400 与 500 之间的视觉间距和 500 到 600 之间完全一致。手动调 HSL 色阶以达到同样的均匀度,每个颜色都是数小时的工作;OKLCH 免费送您。

谨慎使用吸管做跨标签颜色匹配

EyeDropper API(截至 2026 年仍是 Chromium 独占)让您在屏幕任意位置点击 —— 包括浏览器之外 —— 以取样该像素的颜色。在匹配截图、视频帧或另一应用 UI 中的颜色时很有用。把结果当作起点,而不是最终值 —— 屏幕渲染会施加可能与源文件不同的颜色管理。对于规范的品牌色,请始终从设计源(Figma、Sketch、品牌指南 PDF)拿 hex,而不是从截图吸色。

用 #hex=... 链接为可共享的调色板决策加书签

当前颜色会自动以 #hex=... 或 #oklch=... 的形式编码进 URL 哈希。复制 URL,粘贴到 Slack 线程或 GitHub issue 里,打开的人会落在完全相同的颜色上。在「品牌蓝」需要指向某一具体 OKLCH 三元组的设计评审讨论中很有用。哈希在每次变更时更新,因此您地址栏中的 URL 始终是当前实时颜色 —— 给它加个书签,以便日后回到某个特定调色板。

常见问题