在线取色器
上传截图或照片，鼠标移到哪就取哪一点的颜色，一键复制 HEX / RGB / HSL，还会自动算出这张图的 8 色主色调色板。图片不上传服务器，浏览器本地读像素，无广告无水印。
点击选择 或拖拽 / 粘贴一张图片
JPG · PNG · WebP | 取准确色值建议用 PNG 截图
把鼠标移到图片上取色，点击可锁定当前颜色
点色值方块即可复制，可直接粘进 CSS、Figma、PS 拾色器。
这张图的主色调色板（按覆盖面积排序，点击复制）
常见问题
取到的颜色和设计稿里的不一样，差了一两个数值
几乎都是 JPEG 压缩造成的。JPEG 把画面按 8×8 像素块做频域压缩，纯色区域边缘会渗出几像素的渐变噪点，取到的值可能偏 1~3。两个解决办法：截图时选 PNG 格式（macOS 默认就是 PNG，Windows 截图工具要手动选）；或者在大片纯色区域的正中间取色，别贴着文字和边框取。另外注意屏幕色彩配置文件（Display P3 vs sRGB）也会让同一张图在不同设备上看起来有差异，但取到的数值本身是文件里的真实值。
HEX、RGB、HSL 三种格式该用哪个？
写 CSS、填 Figma、跟设计师报颜色，用 HEX，最通用最短。需要在代码里改透明度或做插值动画，用 RGB，因为可以直接写成 rgba(r,g,b,.5)。要基于一个主色推导出整套深浅色阶，用 HSL——保持 H 和 S 不动，只把 L 从 95% 调到 15%，就能得到一条视觉上连贯的色阶，这是做设计系统最省事的办法。
调色板的 8 个颜色是怎么算的？可靠吗？
用的是 中位切分法（median cut）：把采样到的像素扔进 RGB 三维立方体，反复沿着当前跨度最大的通道把盒子对半切，切到 8 个为止，每个盒子取平均色，最后按盒子里的像素数量从多到少排序。所以第一个色通常是背景主色，最后几个是点缀色。对照片和 UI 截图都稳定；对渐变图会给出渐变路径上的几个采样点，这是预期行为。为了速度，超过 12000 像素的图会等间隔抽样，不影响主色判断。
能取网页上任意位置的颜色吗？
本工具只能取你上传的图片。浏览器出于安全限制，网页里的 JS 无法读取页面外或其他标签页的像素。要取网页颜色，先用系统截图（Win+Shift+S / Cmd+Shift+4）截下来再拖进来。Chrome 开发者工具的 Elements 面板里也自带拾色器，可以直接吸取当前页面的元素颜色。
图片会上传吗？有大小限制吗？
不上传。取色靠 Canvas 的 getImageData 直接读本地像素，图片数据不离开设备。没有张数和体积限制（受设备内存约束），不用注册、没有广告、断网也能用。产品设计稿、后台截图、还没发布的物料，这些最需要取色也最不该外传的东西，放这儿是安全的。
手机上能用吗？
能。手机上用手指在图片上滑动即可取色，色值会实时更新，松手后点色值方块复制。调色板功能完全一样。iOS Safari 和 Android Chrome 都实测可用。
关于从图片里取色，几个实用结论
取色这件事看着简单——读一个像素的 RGB 值而已。但真正用起来会发现，取到的数值经常「不对」：同一块看起来纯白的背景，在不同位置取出来是 #FFFFFF、#FEFEFE、#FDFEFD 三个值。这不是工具的问题，是图片本身就没有你以为的那么干净。理解这一点，比换十个取色工具都有用。
为什么纯色区域会取出好几个值
罪魁祸首是有损压缩。JPEG 把图片切成 8×8 的块，对每块做离散余弦变换后丢掉人眼不敏感的高频信息。这个过程对大面积纯色是安全的，对颜色突变的边缘是有破坏性的。所以一张 JPG 截图里，文字周围、按钮边框附近、图标轮廓外侧，都会有一圈几像素宽的「脏色」。你要是恰好在那儿取色，拿到的就是被污染过的值。
实测一个例子：把纯 #1A73E8 的蓝色按钮截成 PNG，取色 100% 是 #1A73E8；同一张图存成 quality 80 的 JPG，按钮中心还是 #1A73E8，但边缘 2 像素内会出现 #1B71E5、#1974EA 这类偏差值。所以规则很明确：要精确色值，用 PNG 截图，并在色块中心取。
另一个容易忽略的坑是屏幕缩放。在 2x Retina 屏上截图，系统实际截的是物理像素，一个 CSS 像素对应 2×2 个物理像素，边缘会有抗锯齿产生的中间色。这也是为什么细线条和小字号文字的颜色最难取准。
三种色值格式的分工
| 格式 | 长什么样 | 什么时候用它 |
|---|---|---|
| HEX | #1A73E8 | 写 CSS、填设计工具、口头/文档沟通颜色。最通用，也最短 |
| RGB | rgb(26, 115, 232) | 需要加透明度（rgba）、写渐变、在 JS 里做颜色插值计算 |
| HSL | hsl(217, 80%, 51%) | 从一个主色推导整套色阶、批量调明暗、做深色模式适配 |
HSL 被严重低估了。它把颜色拆成色相（H，0-360 的色环角度）、饱和度（S）、亮度（L），这恰好符合人描述颜色的方式——「同样的蓝，浅一点」在 HSL 里就是把 L 从 51% 改到 80%，在 HEX 里你得靠猜。做设计系统时，取一个品牌主色的 HSL，固定 H 和 S，把 L 按 95/85/70/55/40/25/15 排开，一套七级色阶就出来了，而且视觉上天然协调。
主色提取：为什么不是「数哪个颜色出现最多」
最朴素的做法是统计每个 RGB 值出现的次数，取前 8 名。这个方法在照片上会彻底失败：一张风景照可能有 20 万个不同的 RGB 值，每个只出现几次，前 8 名是随机噪声。而且会把肉眼看来同一个颜色的几千个细微变体当成不同颜色。
所以要用聚类思路。中位切分法（median cut）的做法是几何式的：把所有像素当成 RGB 三维空间里的点，装进一个包围盒，然后找当前跨度最大的那个维度（比如红色分量从 20 跨到 240），沿中位数把盒子劈成两半，对每个子盒子重复，直到盒子数量等于你要的颜色数。每个盒子取平均色，就是一个代表色。
这个算法的好处是速度快（不用迭代收敛，一遍切完）、结果稳定（同一张图每次跑出来一样，K-means 会因随机初始化而波动）、且天然按覆盖面积排序——盒子里像素多的就是画面里占比大的颜色。缺点是对小面积高饱和的点缀色不够敏感，比如一张灰色界面里的一个红色小按钮，可能进不了前 8。真要抓点缀色，就在图上手动吸取。
本工具还额外跳过了 alpha 小于 128 的透明像素。这一步很重要：透明 PNG 的透明区域在 Canvas 里读出来是 (0,0,0,0)，不跳过的话调色板第一个色永远是黑色，毫无意义。
取色之后：从一个颜色到一套配色
拿到主色只是开始。几个可以直接套用的推导规则：互补色把 H 加 180，用来做强调色和警示色；邻近色把 H 加减 30，用来做同色系的层次区分；三分色把 H 加减 120，适合做数据可视化里需要明确区分的几个系列。这些都在 HSL 下改一个数字就能得到，这也是为什么建议你复制 HSL 而不只是 HEX。
还有一条经验：从照片里提取的配色天然协调，因为真实世界的光照本身就统一了色调。设计配色卡壳的时候，找一张氛围对的照片扔进取色器，用它的调色板做界面配色，成功率比自己凭空调高得多。这也是 Dribbble 上大量「Color palette from photo」类作品的底层逻辑。
为什么这个工具不需要服务器
取色是纯本地计算——getImageData 拿到像素数组，索引一下就是颜色值，调色板的中位切分也是几十毫秒的事。既然一次网络请求都不需要，就没有理由把你的图传出去。产品设计稿、内部后台截图、未发布的物料、客户的品牌资产，这些恰恰是取色需求最集中、也最不该经过第三方服务器的东西。本站所有工具都遵循这个原则：压缩、格式转换、圆角图片、清除 EXIF 全部在浏览器里跑，把网络断了也能正常用。