PNG、JPG、WebP 转 ICO 为什么会糊：尺寸、透明边缘和 contain/cover 这样选

这份回答依据图叮当前公开页和实现逐项核对，重点解释四个容易混在一起的问题：小尺寸为什么会糊、透明边缘为什么会发黑或发白、contain 与 cover 怎么选，以及预览应该看多大。这里不把大图观感当成小图质量，也不把“透明留白”说成自动去背景。

问：PNG、JPG、WebP 转成 ICO 后为什么会糊？

一张 16×16px 的图只有 256 个像素。原图里的细线、阴影、渐变、小字和复杂纹理，都要被压进这 256 个位置。细节密度过高时，缩放只能合并相邻颜色，原本清楚的线条可能变灰，间距可能粘在一起，小字也可能失去可辨认的笔画。

因此，适合做 ICO 的源图通常不是细节最多的版本，而是轮廓明确、明暗反差足够、主体位置稳定的版本。很细的描边缩到 16px 后，可能连一个完整像素都占不到；主体若只靠微弱阴影与背景分开，小尺寸下也容易失去层次。

格式转换不会补回源图已经丢失的细节。JPG 上已有的块状压缩、边缘噪点和模糊会一起进入 ICO。遇到这种源图，可先看图片压缩后出现块状和模糊的处理思路，判断该换回母版，还是先处理源图再转换。对像素尺寸仍不熟悉，也可以先理清尺寸、分辨率和长宽比的关系。

问：PNG 一定比 JPG 更适合做 ICO 吗？

不一定。PNG 可以保存透明通道，WebP 也可能带透明信息；JPG/JPEG 没有透明通道，原图里的白底或黑底就是实际像素，不会因为转成 ICO 自动消失。

选择 PNG 并不能保证图标清楚，选择 JPG 也不等于一定模糊。小图是否清楚，主要看源图轮廓和缩放后的信息密度；背景能否透明，则取决于源图有没有可用的透明信息。想核对三种格式的边界，可以参考PNG、JPG、WebP 的使用区别。

如果目标是无底色图标，较稳妥的源文件是边缘已经处理干净的透明 PNG 或透明 WebP。源图若还带着实心白底，转换工具只能把这块白色当作画面内容。需要去除背景时，应在转换前先完成抠图；透明背景 PNG 的制作方法讲的是这道前置处理。

图叮当前还接受 HEIC/HEIF；GIF 只读取第一帧，不会把动画装进 ICO。输入格式决定可用的源信息，最终的小尺寸辨识度仍要另行验收。

问：contain 和 cover 应该选哪一个？

contain 会把整张源图等比缩放到目标正方形内，完整保留并居中，不拉伸。源图不是正方形时，空出来的区域会成为透明留白或指定颜色。它更适合边缘不能丢的标志、带外框的图形，以及主体已经贴近画布边界的图片。

cover 会把源图等比放大到铺满目标画布，再从中心裁掉超出的部分，同样不会拉伸。它适合主体集中在中间、画布需要铺满的图形；代价是靠近上下或左右边缘的内容可能被截掉。

保全主体与铺满画布，需要做不同取舍

两种方式没有统一的优胜者。判断时只需问：这张图最不能失去的，是完整轮廓，还是铺满画布的视觉面积？前者选 contain，后者再考虑 cover。源图本来就是正方形且四周留白合适时，两种方式的差异可能很小。

还要分清“透明留白”和“去背景”。contain 新增的空白区域可以是透明的，但它不会删除源图里已有的白底、黑底或杂色；cover 通过裁切铺满画布，也不会识别并清除这些背景。

问：透明图标为什么会出现白边或黑边？

图标边缘经常不是完全透明或完全不透明，而是一圈半透明像素。它们负责让曲线看起来平滑，也会受到查看背景的影响。同一枚图标放在白色窗口、深色任务栏和透明棋盘格上，边缘观感可能不同。

出现白边或黑边时，按三个方向排查：

• 源图是否曾经贴在白底或黑底上导出，边缘颜色已经写进像素；
• 抠图后是否残留一圈半透明杂色；
• 当前查看器是否给透明区域加了固定底色，导致预览与实际使用环境不同。

图叮图片转 ICO 当前使用浏览器的高质量平滑缩放，但不会自动锐化，也不会自动清理黑边、白边或边缘颜色污染。较稳妥的检查方法，是在转换前把透明源图分别放到浅色和深色背景上看一遍；两种背景都没有明显光圈，再进入 ICO 转换。

问：为什么 512px 预览清楚，下载的 16px 图标仍然难看？

工具的大预览最多 512px，适合检查主体有没有选错、裁切方向是否合理，却不能代替小尺寸验收。512px 看起来锋利，只能说明大图预览正常，无法证明 16px 的内部间距仍然分得开。

下载后，至少按实际大小检查 16、24、32px 三档，不要把小图放大几倍再判断。检查外轮廓能否一眼认出，中间的孔洞、间距和负形是否粘连，细描边有没有变灰或消失，cover 是否切掉关键边缘，以及 contain 的透明留白是否让主体显得过小。

如果 16px 已经辨认不出主体，继续调转换参数通常收效有限。更有效的办法是回到源图，减少小字、弱阴影和细碎纹理，适当加粗关键轮廓，再重新转换。小尺寸图标追求的不是保留所有细节，而是在有限像素里保住最重要的识别特征。

问：ICO 里的 DIB、PNG 帧和 ZIP 打包会不会降低画质？

图叮生成的 ICO 中，16–128px 使用 32-bit BGRA DIB，256px 使用 PNG frame。同一个 ICO 里看到两种帧编码，不代表文件损坏。它们共同承载不同尺寸的图像内容，检查时应把注意力放在最终帧的尺寸、透明度和实际观感上。

批量结果装在 ZIP 包里时，打包使用 STORE，不会对图片再做一次有损压缩。ZIP 不会额外把图标压糊。真正可能改变观感的环节发生在更早的位置：源图质量、小尺寸重采样、contain 或 cover 的选择，以及透明边缘本身。

问：用图叮图片转 ICO 时，怎样减少返工？

准备好源图后，可以打开图叮图片转 ICO 工具完成转换。它支持 PNG、JPG/JPEG、WebP、HEIC/HEIF，以及 GIF 第一帧；默认可选 16、24、32、48、64、128、256px 七档尺寸。

操作时先用 contain 看完整轮廓，再根据画布占用情况决定是否改用 cover。如果两种模式在大预览里差不多，仍要以下载后的 16、24、32px 为准。透明边缘有问题就回到源图处理；小尺寸结构粘连就简化轮廓，不要期待转换器自动锐化或补画细节。

图片解码、缩放、ICO 写入和 ZIP 打包都在当前浏览器完成，图片文件不会上传到处理服务器；最终生成需要登录。若你还遇到本文没有覆盖的尺寸、透明边缘或查看器差异，可以从工具页的反馈入口提交具体文件类型、目标尺寸和复现步骤，便于继续补充这份 FAQ。