HEX 转 OKLCH 转换器

什么是 HEX 转 OKLCH 转换器?

// sRGB hex → OKLCH per W3C CSS Color 4 + Ottosson 2020
// References: https://www.w3.org/TR/css-color-4/#color-conversion-code
//             https://bottosson.github.io/posts/oklab/
// Worked example: #3b82f6 (Tailwind blue-500) → oklch(0.629 0.193 263.4)
function hexToOklch(hex) {
  const h = hex.trim().replace(/^#/, '');
  const srgb = [0, 2, 4].map(i => parseInt(h.slice(i, i + 2), 16) / 255);
  // sRGB → linear-sRGB (CSS Color 4 §11.2 piecewise gamma)
  const lin = srgb.map(v => v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4));
  const [lr, lg, lb] = lin;
  // linear-sRGB → XYZ D65 (CSS Color 4 §15.1 matrix)
  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), 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;
  return `oklch(${L.toFixed(3)} ${C.toFixed(3)} ${H.toFixed(1)})`;
}
console.log(hexToOklch('#3b82f6')); // → oklch(0.629 0.193 263.4)

核心特性

HEX 转 OKLCH 转换器替代品对比

HEX 转 OKLCH 示例

#3b82f6

#FF5733

#FF1744

#0f172a

#3b82f6

常见 HEX → OKLCH 转换(Tailwind v4)

10 个常用 Tailwind v4 默认调色板中间档及其 HEX 与 OKLCH 等价值的参考表。数值匹配 Tailwind v4 公布的调色板精度(L 与 C 三位小数,H 为整数或一位小数)。

如何使用 HEX 转 OKLCH 转换器

1. 1

   把 HEX 代码粘贴到 HEX 字段

   把任意 HEX 值丢进 HEX 输入框 —— 带或不带前导 `#`、3 位简写(`#F73`)、6 位完整形式(`#3b82f6`)、4 位 alpha 简写(`#F738`),或者 8 位 alpha 完整形式(`#FF573380`)。解析器会把全部 5 种输入形态在派生 OKLCH 之前归一到同一内部颜色。大小写无关(`#3b82f6` 与 `#3B82F6` 解析结果完全相同)。非法字符或位数错误会产生一个安静的行内错误;合法 HEX 则会实时刷新其他每一个格式字段,包括 OKLCH。

2. 2

   从 OKLCH 字段读取 OKLCH 三元组

   OKLCH 字段以 CSS Color 4 现代形式呈现该值:不透明颜色为 `oklch(0.629 0.193 263.4)`,带 alpha 时为 `oklch(0.629 0.193 263.4 / 0.5)`。L 取三位小数(与 Tailwind v4 公布的精度一致),C 取三位小数,H 取一位小数(度)。工具内部以 OKLCH 作为事实源,意味着底层浮点精度在其他每个字段上都被保留 —— 往返回到 HEX 比特稳定,这与那些以 HSL 作枢轴的老式转换器不同,后者每次往返会漂移一到两度。

3. 3

   点击「复制」抓取 OKLCH 字符串

   每个格式卡片右侧都有一个复制按钮。一键即可把值送到剪贴板 —— 按钮标签短暂闪现「Copied!」以便您知道。复制出来的字符串是规范的 CSS Color 4 语法(`oklch(0.629 0.193 263.4)`),可直接放进 Tailwind v4 的 `@theme` 块或 shadcn/ui 的 CSS 变量定义。要输出特定平台的代码(CSS 自定义属性、Tailwind v4 token、SwiftUI、Compose、Flutter),请使用取色器下方的「复制为代码」区段 —— 那些片段会按每个平台原生期望的格式输出。

4. 4

   查看 Display P3 / Rec.2020 色域徽章

   三个色域徽章(sRGB、Display P3、Rec.2020)显示当前颜色是否落在每个空间的可再现范围内。如果 sRGB 徽章亮红而 P3 是绿,这就是一个广色域 OKLCH,会在 Apple 硬件(iPhone、iPad、2017 年及之后的 MacBook)上渲染得饱和,但在传统 24 位显示器上会去饱和。**Snap to sRGB** 按钮使用二分色度收缩(CSS Color 4 §13 非规范性算法),在保留 L 与 H 的同时把颜色收缩进 sRGB,产出一个可经由 `@supports not (color: oklch(0 0 0))` 兜底交付的 HEX。

5. 5

   同屏可见:RGB、HSL、OKLAB、HSV、HWB、CMYK、命名颜色

   您粘贴的同一个 HEX 也会点亮其他 8 个格式字段 —— 给 canvas 调用和硬件的 RGB,给遗留 CSS 变量的 HSL,给调色板数学与色盲矩阵的 OKLAB,给设计师取色器工作流的 HSV 与 HWB,给印刷估算的 CMYK,以及给文档文案的最接近 CSS 命名颜色。您绝不会被锁死在仅 HEX → OKLCH。取色器(SL 方块 + 色相滑块 + alpha 滑块)同时驱动全部 9 种;在 Chromium 系浏览器上,EyeDropper 按钮可以从屏幕任意像素取样,包括浏览器之外。

HEX / OKLCH 常见错误

设置 OKLCH C = 0.3,期望「30% 饱和度」:
oklch(0.7 0.3 250) → 对蓝色可能超出 sRGB 色域
广色域颜色在传统显示上渲染去饱和。

把 C 当作绝对色度,核对色域徽章:
oklch(0.7 0.15 250) → 在这一 L+H 配对上舒服地落进 sRGB
用徽章找出落进目标色域的最大 C。

把 HSL 的 L 百分比直接复制到 OKLCH:
hsl(220 50% 30%) 移植为 oklch(0.30 0.10 220)
两个颜色在亮度上看起来明显不同。

从原始 HEX 重新派生 OKLCH,不要从 HSL 移植:
HEX 源 → OKLCH 转换 → oklch(0.34 0.08 254)
感知 L 保持正确;调色板感觉均匀。

不核对 sRGB 色域就交付 oklch(0.7 0.4 30):
P3 显示渲染饱和红;sRGB 显示渲染去饱和
品牌色在用户硬件之间看起来不一致。

核对 sRGB 色域徽章,必要时 Snap to sRGB,通过 @supports 分层:
@supports (color: oklch(0 0 0)) { --primary: oklch(0.7 0.4 30); }
@supports not (color: oklch(0 0 0)) { --primary: #ef6b50; }
P3 硬件拿到广色域值;sRGB 硬件拿到 snap 后的兜底。

只用 OKLCH 定义品牌色:
:root { --primary: oklch(0.629 0.193 263.4); }
IE 11 与旧版 iOS Safari 完全不渲染颜色。

通过 @supports 分层实现优雅降级:
:root { --primary: #3b82f6; }
@supports (color: oklch(0 0 0)) { :root { --primary: oklch(0.629 0.193 263.4); } }
现代浏览器拿到 OKLCH;遗留浏览器拿到 HEX 兜底。

用 lch() 代替 oklch() 期望同样的结果:
lch(60% 50 240) ≠ oklch(0.6 0.15 240) —— 完全不同的颜色
跨空间复制粘贴时,值就这样悄悄错了。

选一个空间,留在里面:
oklch(0.629 0.193 263.4) 用于现代设计系统
或 lch(60% 50 240) —— 但不要在不重新转换的情况下直接换函数名

谁在使用 HEX 转 OKLCH

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

Tailwind v4 在 2025 年 1 月为其默认调色板统一采用 OKLCH。迁移一个使用基于 HEX 品牌色的 v3 代码库,意味着把每个 HEX 转成 OKLCH 并把结果放进新的 `@theme` 块。把每个 HEX 粘到这里,复制 `oklch()` 值,定义 `--color-primary: oklch(0.629 0.193 263.4)` 及其同伴。实时色域徽章会标出任何超出 sRGB 的颜色,您可以决定为 Display P3 用户保留广色域值,还是收进 sRGB。

shadcn/ui 主题作者构建自定义调色板

shadcn/ui 的 CSS 变量主题对每个 token(`--background`、`--foreground`、`--primary` 等)都使用 OKLCH。自定义主题从一个基础品牌 HEX 派生,先转成 OKLCH,然后扫描 L 得到亮/暗变体。粘贴品牌 HEX,读出 OKLCH 三元组,在保持 C 与 H 固定的同时扫描 L 把主题其余部分构出来。与规范的 shadcn 工作流完全匹配。

设计系统作者生成感知均匀的色阶

通过在 OKLCH 上以等增量扫描 L 通道、保持 C 与 H 固定,生成 50/100/200/…/900 色阶。相邻档之间的视觉间隔在所有色相上一致 —— 品牌色调色板真正需要的就是这个。Tailwind v4 的默认调色板正是用这种构造,shadcn/ui 也照搬。粘贴每一个品牌 HEX,读出 OKLCH,通过算法或取色器下方的「浅色 / 深色 / 灰调」面板生成色阶。

无障碍工程师在 OKLCH 空间核验对比度

WCAG 2.1 与 APCA 对比度都以解析后的 sRGB 颜色计分,而不是 OKLCH 三元组 —— 但知道一个品牌色的 OKLCH L 让对比度调整更可预测:L 上调 0.1 即可对白通过 AA,L 下调 0.1 即可对黑通过 AA。同屏的 OKLCH + WCAG + APCA 视图让这种关系一目了然。粘贴品牌 HEX,观察对比度徽章,在 OKLCH 中调整 L(比 HSL 更可预测),直到这一配对在两个指标上都通过。

为现代显示设备构建广色域颜色 token 的 Web 开发者

多数 Apple 设备自 2017 年起(以及许多现代 Android 设备)原生渲染 Display P3。把品牌强调色定义在 OKLCH 上,让您可以表达 HEX 编码不了的、仅 P3 才有的高饱和度红与绿。粘贴现有 HEX 读出其 OKLCH,然后把 C 通道推到 sRGB 上限之上,获得额外的 P3 饱和度。色域徽章确认新值能落进 P3(在仅 sRGB 屏幕上通过浏览器色度压缩优雅降级)。

讲授「感知亮度 vs 几何亮度」的教育者

同屏的 OKLCH + HSL 视图让「感知亮度与几何亮度」的区别一目了然。粘一个饱和绿与一个饱和蓝,两者在 HSL 上同处 L=50%;它们的 OKLCH L 值会明显不同,因为 OKLCH 测量的是真实的感知亮度。拖动 HSL 色相滑块,观察 OKLCH 的 L 在您保持 HSL L 不变时如何波动 —— 那条曲线就是 gamma 怪癖的可视化。一个适合课堂演示的、说明设计系统为什么迁到 OKLCH 的例子。

开源维护者现代化 token 文档

较老的设计系统文档通常只列 HEX 代码作为品牌色。现代化到 OKLCH 意味着同时展示两种空间下的同一颜色 —— HEX 用于代码块兼容,OKLCH 用于规范表与现代 token 定义。把每个 HEX 粘进来,复制 OKLCH 输出,更新文档。可分享的 URL 哈希也让贡献者能在 GitHub issue 中无歧义地链接到讨论中那一确切颜色。

HEX 转 OKLCH 的数学与流水线

HEX → OKLCH 是 7 步流水线

转换会经过 5 个中间表示:HEX → 整数 sRGB → 归一化 sRGB(0–1) → 线性 sRGB(gamma 解码) → CIE XYZ D65 → OKLAB → OKLCH。每一步都是来自主要来源、定义良好的矩阵或分段函数。工具在每次按键时跑完整流水线;数学足够快(微秒级),无需防抖。在 OKLCH 旁同屏展示中间的 RGB 三元组,让您可以通过观察 RGB 通道来调试一个意料之外的 OKLCH 值。

CSS Color 4 §11.2 Gamma 函数

sRGB → 线性 sRGB 的转换使用 CSS Color 4 §11.2 的分段函数:`v ≤ 0.04045 ? v/12.92 : ((v + 0.055) / 1.055)^2.4`。分段形式(在接近零处带一段小的线性段)避免了纯指数形式在很暗颜色上的数值不稳定。这是 ICC 配置文件用于编码 sRGB 的同一函数,也是浏览器在渲染 HEX 代码时内部使用的同一函数。OKLCH → HEX 的逆向应用相同函数的反函数:`v ≤ 0.0031308 ? v * 12.92 : 1.055 * v^(1/2.4) - 0.055`。

CSS Color 4 §15.1 矩阵:线性 sRGB ↔ XYZ D65

CSS Color 4 §15.1 的矩阵把线性 sRGB 在 D65 白点下转换到 CIE XYZ:`X = 0.4124564 R + 0.3575761 G + 0.1804375 B`、`Y = 0.2126729 R + 0.7151522 G + 0.0721750 B`、`Z = 0.0193339 R + 0.1191920 G + 0.9503041 B`。Y 行给出 sRGB 的相对发光强度公式。这套矩阵就是每个色彩管理库 —— 包括 ICC、Adobe Color Engine 与开源的 LCMS 流水线 —— 使用的同一套矩阵。OKLCH → HEX 反向应用 §15.1 的逆矩阵。

Ottosson 2020 OKLAB 矩阵与立方根步骤

XYZ D65 → OKLAB 的转换使用 Björn Ottosson 2020 年 OKLAB 论文中公布的两个矩阵与一个立方根步骤。第一个矩阵把 XYZ 变换到一个 LMS 锥响应空间(松散建模人眼 L/M/S 锥灵敏度)。对每个通道取立方根以非线性地压缩动态范围(感知均匀性的修正步骤)。第二个矩阵把立方根化后的 LMS 变换到 OKLAB 的 L/a/b 坐标。三项操作都使用论文参考实现中公布的精确值;不做重新推导,不做四舍五入。OKLCH → HEX 反向应用这些矩阵的反矩阵。

OKLAB ↔ OKLCH 是笛卡尔到极坐标

OKLAB 的 `a` 与 `b` 轴构成一个与 L 轴正交的色度平面。OKLCH 用极坐标编码这个平面:`C = sqrt(a² + b²)`(到灰色的欧式距离)、`H = atan2(b, a) * 180 / π`(角度,单位为度,包到 0–360°)。反向:`a = C * cos(H * π / 180)`、`b = C * sin(H * π / 180)`。极坐标形式比 OKLAB 更适合设计 token 存储,因为色相 Hue 是一个稳定的轴 —— 旋转色相不会像在 OKLAB 中旋转 `a` 或 `b` 那样意外地穿过灰色淡入淡出。

色域检测:通道范围检查

一个颜色被认为在目标空间(sRGB、Display P3、Rec.2020)内,当且仅当转换到该空间原色后,每一通道都落在 `[-ε, 1 + ε]` 内,其中 `ε = 1e-7`,以吸收边界附近的浮点精度噪声。任何一通道超出范围时,该空间的色域徽章变红。OKLCH 在色域上无上界 —— `oklch(0.7 0.4 30)` 是一个合法坐标,但可能超出 sRGB 的每通道 256 字节空间。检查在每次按键时运行;结合 Snap to sRGB,这个组合抓住了最常见的落地坑(广色域 OKLCH 在传统屏幕上显示不正确)。

Snap-to-sRGB 二分色度收缩

Snap to sRGB 与 CSS Color 4 §13 的非规范性色域映射算法匹配:把 L 与 H 固定在当前值,在 C ∈ [0, currentC] 上做二分搜索,找到使其 sRGB 转换仍在色域内的最大 C。搜索至多 30 次迭代(精度约 10⁻⁹),对视觉准确性来说绰绰有余。保留 L 与 H 意味着 snap 后的颜色读起来仍是同一个色相家族、同样的感知亮度 —— 它只丢饱和度。我们不直接裁剪 RGB 通道,因为那会明显扭曲色相(尤其是蓝色,会向紫色裁剪)。

HEX / OKLCH 工作流最佳实践

在新代码中以 OKLCH 作为规范 token 格式

对任何在 2025 年及以后交付的设计系统,以 OKLCH 定义品牌色与调色板色阶。L 轴自动给出感知均匀色阶;色度轴能表达 HEX 编码不了的广色域颜色。通过 `@supports not (color: oklch(0 0 0))` 或构建期 PostCSS 为较老浏览器保留 HEX 兜底,但在您的 token 仓里以 OKLCH 作为事实源。Tailwind v4 与 shadcn/ui 都按这种方式交付;新项目可以无障碍地照搬。

扫 L、固定 C 与 H,生成色阶

规范的 OKLCH 色阶构造:锁定 C 与 H,以等增量扫 L。一份 9 步色阶 `oklch(L 0.15 263)`,L = 0.1、0.2、…、0.9,产出视觉均匀间距,每一档都是。Tailwind v4 内部正是这样做。除非您刻意想让色阶的色度强度变化(罕见),否则不要在扫 L 的同时扫 C。不要在不同档之间漂移 H —— 哪怕只是 5° 的漂移也会让色阶感觉错乱。

匹配 Tailwind v4 的精度:L 与 C 三位小数、H 一位小数

Tailwind v4 默认调色板公布的 OKLCH 值在 L 与 C 上取三位小数,在 H 上取一位小数 —— blue-500 即 `oklch(0.629 0.193 263.4)`。在您自己的 token 中匹配这一精度,意味着粘进配置的工作流产出与 Tailwind 默认完全一致的值,diff 工具不会标出虚假差异。工具的默认舍入遵循这一约定;粘进 `@theme` 块比特精确。

用 Display P3 色域检查跑一遍广色域 OKLCH

如果您面向现代 Apple 硬件(2017 年及以后的 iPhone、iPad、MacBook)或交付 HDR 感知内容,色域徽章让您可以把 C 推到 sRGB 上限之上,获得额外的 P3 饱和度。浏览器内置的色度压缩会防止颜色在仅 sRGB 屏幕上裁剪。除非您确知整批受众都在传统显示设备上,否则不要默认预先 snap 到 sRGB —— 那会丢掉 P3 硬件能渲染的 30%+ 饱和度。

通过 @supports 为 2023 年之前的浏览器提供 HEX 兜底

尽管常青浏览器对 `oklch()` 的支持现在已达 94%+,长尾(IE 11、旧版 Android Chrome、内嵌 webview)仍需要兜底。把 token 包在 `@supports (color: oklch(0 0 0))` 里,在另一分支给出 HEX 变体。Snap to sRGB 的输出正是那个兜底 —— 由当前 OKLCH 三元组在保留 L 与 H 的前提下自动生成。构建期的 PostCSS 插件,如 `postcss-oklab-function`,也可以在编译时把 sRGB 近似内联进来。

在 token 中同时记录 OKLCH 与源 HEX

当您交付一个 CSS 变量 `--color-primary: oklch(0.629 0.193 263.4)` 时,在注释里附上源 HEX:`/* source: #3b82f6 (Tailwind blue-500) */`。半年后,当有人需要派生相近色阶或对照品牌指南 PDF 核值时,源 HEX 保留了完整的来源信息。OKLCH 单独看是有意义的,但更难一眼辨认;源 HEX 才是大多数队友会先去查的标识。

用 URL 哈希分享实时的颜色决策

每次颜色变更都会自动把 URL 哈希更新为 `#hex=3b82f6` 或 `#oklch=...`。把 URL 复制进 Slack 线程或 GitHub issue,打开它的人会落在同样的颜色、同样的 OKLCH 三元组上。这比在聊天里粘贴一个 OKLCH 字符串更可靠 —— 收件人偶尔会打错小数,或包错精度 —— 也让设计评审讨论可以指向某一确切颜色,而不是「上周二聊过的那个品牌蓝」。哈希永远不会传到服务器。

常见问题