BMP 转 WebP v1.0

BMP转WebP是常见图片格式转换里压缩幅度最大的一种：一张1,440,674字节的BMP位图转换后只剩181,880字节，体积减少87%。BMP把每个像素原样写进文件、完全不做压缩，WebP则是目前网页上压缩效率最高的常用格式，两者之间正好是从“最不适合上网”到“最适合上网”的最短路径。DocPivot的BMP转WebP转换器在浏览器本地完成解码与编码，一次最多处理30个文件，源文件真正声明了透明通道时，透明背景会被完整保留。如果你要的是逐像素精确复制而不是更小的体积，BMP转PNG工具才是对的那一页。

1.4 MB变182 KB：这次转换到底能省多少

实测一张1,440,674字节的BMP文件，输出WebP为181,880字节，省下87%。这个比例在整个转换家族里排第一，原因不在WebP有多突出，而在BMP根本没有压缩这一步——文件体积等于宽×高×每像素字节数，一张1920×1080的24位BMP固定占用约6 MB，画面是纯色还是复杂照片都一样大。

87%是典型值，实际幅度随画面内容浮动。截图、软件界面、流程图这类大面积平涂的图像能压得更多；噪点密集的实拍照片会低一些。如果手里的BMP本身是从JPG另存出来的，压缩后体积也会更接近原始JPG。想横向比较不同输出格式的体积差异，可以先用图片压缩工具跑一遍，或者对照BMP转JPG工具的结果——JPG不支持透明，但能被更老的软件打开。

国内在线转换工具普遍没解决的三个问题

中文搜索结果里的BMP转换页面几乎都是通用型“图片格式转换器”，把BMP和JPG、PNG、GIF塞在同一个下拉框里，三个具体问题始终没人正面回答。

第一，体积门槛卡的恰好是BMP。国内转换站常见的提示是“图片大小不超过5M”，超过10 MB则建议改用Photoshop。而BMP是所有常用格式里最容易突破这条线的：一张4K截图存成24位BMP就有24 MB，直接被挡在门外。本工具在本地读取文件，没有上传体积这一关。

第二，透明度被默认拍平。大多数通用转换器把32位BMP的第四个字节当作填充位丢弃，白底或黑底就这样烙进了输出文件。做PNG转WebP时这个问题不明显，因为PNG的透明信息不会被误读；BMP的头部结构有好几种，判断逻辑必须写对。

第三，每日次数与批量限制。免费额度普遍是每天25次，或者一次只让转一个文件。做JPG转WebP时一次转几十张是常态，BMP同样如此，尤其是从设备端批量导出的截图。本工具单次接受30个文件，打包成一个ZIP返回，没有每日上限。想一次处理多种源格式，可以用图片格式转换工具统一入口。

32位BMP的透明通道：为什么有的留得住，有的留不住

同样是32位BMP，转换后有的保留透明、有的变成不透明，差别在文件头部那几十个字节，跟转换工具好不好没有关系。

BMP的信息头有多个版本。较老的BITMAPINFOHEADER长40字节，它只描述宽、高、位深和压缩方式，并不声明第四个通道的用途。在这种头部下，32位像素被写成BGRX，最后一个字节是对齐用的填充位——微软自家的图像解码器也明确忽略这个字节，因为大量旧文件在这里填的是无效数据。浏览器遵循同一套规则，所以这类BMP到达转换环节时已经是不透明的，任何工具都无法凭空还原它。

BITMAPV4HEADER及更新的版本长108字节以上，会用显式的通道掩码写明红、绿、蓝、透明各占哪几位。DocPivot按字节读取头部，识别到掩码就把透明通道一并解出来，交给WebP编码器。WebP自身带有真正的透明通道，因此这一层不会被压平，界面上的背景色选项也会随之隐藏，而不是摆在那里却不起作用。

判断手上文件属于哪一类，最快的办法是转换一次看结果。如果输出仍然不透明，说明源文件的头部没有声明透明信息，用WebP转PNG工具再转一道也补不回来，正确做法是回到原始设计文件重新导出。需要更高压缩率并且不介意兼容性更窄，可以看BMP转AVIF工具。

DocPivot BMP转WebP转换器的核心功能

• 逐字节解码：直接读取BMP的文件头与信息头，按声明的通道掩码取出像素和透明信息，不依赖统一的图像库猜测格式。
• 透明通道保留：源文件声明透明时原样带入WebP，不做白底填充，也不需要事后抠图。
• 质量95编码：用libwebp在质量95下编码。BMP存的是精确像素，这是它第一次经历有损压缩，所以起点定得高。
• sharp YUV模式：专门保护硬边缘。到达这条转换路径的多是截图和图表，文字与线框边缘最怕色度采样带来的毛边。
• 按体积上限反查：填入目标字节数后，在质量5到95之间做二分搜索，最多8次探测，取能塞进上限的最高质量，而不是让你手动试参数。
• 批量30个文件：一次投入30个BMP，输出一个ZIP。三个文件的实测归档包含三条完整条目，整体节省89%。
• 纯本地运行：libwebp编译成WebAssembly在浏览器里执行，文件不离开设备，没有服务器排队。
• 无使用门槛：不需要注册、不需要API密钥、没有每日转换次数上限。

转换前如果还要调整画面尺寸，先用图片尺寸调整工具把长边压到实际展示宽度，省下的体积往往比调质量参数更多；只需要局部画面时，用图片裁剪工具先切掉多余区域。

DocPivot BMP转WebP的使用方法

1. 选择文件。把BMP拖进上传区，或点击选择，一次最多30个。文件在本地被读取，不会发往任何服务器。
2. 确认透明状态。工具解析头部后告知源文件是否带透明通道。带透明时背景色选项自动隐藏。
3. 设定输出方式。默认使用质量95加sharp YUV；需要控制体积就切到“限制在指定大小以内”，填入目标字节数。
4. 开始转换。编码在浏览器内完成，进度条实时更新，单张1.4 MB的BMP通常在一两秒内结束。
5. 下载结果。单个文件保留原文件名，只换扩展名；多个文件打包成一个ZIP一次下载。

如果输出图片要用于公开发布，建议在转换后用图片加水印工具补上归属标识，WebP同样支持带透明层的水印叠加。

什么时候不该把BMP转成WebP

默认设置下的WebP是有损格式，有三类情况应当换一条路。

需要逐像素精确复制时。医学影像、素材母版、需要反复编辑的图层底稿，任何有损压缩都不合适，应该选无损路径，体积大约是原BMP的一半。

接收方的软件打不开WebP时。这是选JPG或PNG的主要理由。老版本Office、部分打印机驱动、一些政务与企业内部系统仍然不认WebP扩展名。遇到这种情况，WebP转JPG工具可以把已经转好的文件再退回去，但画质会经历第二次有损压缩，更稳妥的做法是从BMP直接转JPG。

源文件用的是40字节旧头部时。前面说过，这类32位BMP到达浏览器时已经不透明，转出来的WebP也是不透明的。这不是失误，而是格式本身没有把信息写下来。

与服务器端转换工具的差异

同一张1.4 MB的BMP，交给不同类型的工具，结果和约束都不一样。

差异的根源是架构而不是功能取舍。服务器端工具必须先接收文件才能处理，于是带宽成本转化成体积门槛、每日配额和排队时间；本地转换没有这笔成本，也就没有对应的限制。代价是运算占用你自己设备的资源，处理超大批量时手机会比电脑慢。

实际应用场景

外贸独立站的产品图。工厂交来的产品图常常是BMP，因为拍照或扫描设备默认输出这个格式。整批转成WebP后页面体积降到原来的八分之一左右，海外访问的首屏时间明显缩短，站点图标则用网站图标生成工具另行生成。

企业OA与政务系统导出的截图。不少内部系统的截图功能固定输出BMP，一张就是十几MB。归档或写进工单前转成WebP，服务器存储压力和邮件附件大小同时下降，sharp YUV模式让表格线和小字保持清晰。

微信公众号与小红书配图。公众号编辑器对单图体积有限制，1.4 MB的BMP直接上传会被拒。转成182 KB的WebP后可以顺利插入，图文加载也更快。

网页前端的内嵌资源。小尺寸图标转成WebP后再用图片转Base64工具编码进CSS，可以减少一次HTTP请求，配合本地转换整个流程都不需要联网。

闲鱼与淘宝的商品实拍。老式数码相机和扫描仪导出的BMP直接上传常常超时，转换后单张不到200 KB，批量上架时30张一次处理完，一个ZIP解压即用。

本地处理与《个人信息保护法》的合规边界

图片是否离开设备，在法律层面不是体验问题而是定性问题。《个人信息保护法》把向境外或第三方传输个人信息界定为“对外提供”，需要单独告知并取得同意；《数据安全法》同时要求处理活动遵循最小必要原则。把一张含有人脸、身份证件、工牌或客户资料的BMP上传到第三方转换站，这一步本身就构成了对外提供，无论对方承诺多久删除。

DocPivot的转换全过程在浏览器里完成，libwebp以WebAssembly形式在本地执行，图片数据不产生任何网络请求。这不是隐私承诺的措辞差别，而是数据从未离开设备。对处理员工照片、合同扫描件、客户身份材料的团队来说，这一条决定了工具能不能进入合规流程。

需要额外说明的是元数据。BMP格式本身不携带EXIF，所以没有拍摄时间、设备型号或GPS坐标可供剥离，输出的WebP里同样不会写入这些字段。如果源头是别的格式，先用EXIF信息查看工具确认里面有什么，再用照片元数据清除工具处理干净。

常见问题