批量图片转换器，免费

关于图片格式转换

每种图片格式都有其用途。PNG 无损，适合图形；JPG 非常适合照片，且文件更小；WebP 提供现代化的压缩与高质量。批量转换可节省同时处理多个文件的时间。

JPEG(1992)，照片格式

Joint Photographic Experts Group 于 1986 年 11 月在新泽西州 Parsippany 成立,成员来自 ISO TC97 SC2/WG8 与 CCITT SGVIII。经过六年的委员会工作,CCITT 建议 T.81 的文本于 1992 年 9 月 18 日通过,同样的文本于 1994 年作为 ISO/IEC 国际标准 10918-1 发布。这两份文档的发布是 JPEG 成为世界照片格式的时刻。数学核心是应用于 8×8 像素块的离散余弦变换:每个块被分解为余弦波之和,人类视觉最不敏感的高频分量比眼睛最先注意到的低频分量被更激进地量化。面向用户的「质量」滑块就是这个东西（量化表上的乘数。质量越高意味着除数越小、精度越高、文件越大。质量越低意味着量化后的零越多、熵编码越好,以可见的块状和振铃伪影为代价换来更小的文件。JPEG 在设计上就是有损的:不存在某个质量设置可以让一次 JPEG 往返在数学上与输入完全相同。对于自然场景的照片）人脸、风景、食物,任何带有平滑渐变和连续色调的东西，这无关紧要;损失存在于人类视觉敏感阈值之下,而文件只是无损格式所产出大小的一小部分。对于带硬边、文字、线条画或大面积纯色区域的图像,JPEG 是错误的选择:同一套 DCT 会用振铃伪影(「蚊子噪声」)涂抹尖锐的边缘,并在 8×8 单元之间留下块状边界。

PNG(1996 年 10 月 / 1997 年 1 月)，无损图形格式

PNG（便携式网络图形）由一个 W3C 之外的非正式小组于 1994 年开发，目的是同时解决既有格式的两个问题：GIF 的专利限制（下文详述）和 TIFF 的复杂性。该规范于 1996 年 10 月 1 日获批成为 W3C 推荐标准，并于 1997 年 1 月 15 日由 IETF 以 RFC 2083 发布。纳入勘误的第二版于 2003 年 11 月 10 日成为 W3C 推荐标准；加入 APNG、HDR 支持和 Exif 处理的第三版于 2025 年 6 月 24 日发布。PNG 是无损格式，每个编码字节都可以还原。在内部，PNG 文件是一系列带类型的块（IHDR 头部、IDAT 压缩数据、IEND 文件结束标记，外加用于色彩配置、透明度、伽马和元数据的可选辅助块）。像素数据先由五种行过滤器之一（None、Sub、Up、Average、Paeth）按扫描行预处理以最大化可压缩性，再经过 DEFLATE 压缩，与 zip 文件和 gzip 使用的算法相同。PNG 支持四种颜色模式：灰度、带透明的灰度、索引色（最多 256 项的调色板，即常说的 PNG-8），以及真彩 RGB（PNG-24），可选 8 位透明通道（PNG-32）。透明通道支持每像素 256 级部分透明，正因如此，图标边缘才能在任何背景上抗锯齿，而不会出现 PNG-8 索引透明曾经常见的「白边」。PNG 在设计上同时面向网络格式和归档格式，这种双重角色正是它至今仍是截图、徽标、线稿、图表以及任何像素级还原比文件大小更重要的图像的默认选择的原因。

GIF(1987 年 6 月 15 日)，动画的幸存者与专利大戏

CompuServe 的工程负责人 Steve Wilhite 于 1987 年 6 月 15 日推出 GIF,用以解决一个具体问题:如何在 CompuServe 在线服务的慢调制解调器上分享彩色图像,而又不让文件吃光用户的月度配额。他的团队选择了 Lempel-Ziv-Welch(LZW)压缩算法,并把调色板限制在 256 项。1987 年 CompuServe 不知道的是,LZW 已经在 1985 年被 Sperry Corporation(后来的 Unisys)申请了专利。专利问题在1994 年底公开爆发。Unisys 在 1995 年宣布将对使用该算法的软件（包括 GIF、TIFF 和 PDF）按大约 0.45% 至 0.65% 的营收收取专利费。Web 的开源社区以两条平行的行动作为回应:「Burn All GIFs」运动,以及把 PNG 设计为明确的、无专利的 GIF 替代品。Unisys 的美国专利于 2003 年 6 月到期;在其他司法辖区的对应专利在 2004 年前陆续到期。到 2004 年,GIF 在其历史上第一次彻底摆脱了专利束缚。GIF 之所以幸存,要归功于 PNG(最初)没有的一个特性:动画。它支持一系列带有逐帧延时和透明调色板索引的帧,这让它成为循环表情包和 Web 横幅的通用语言。256 色调色板对照片来说是真的局限,1 位透明度在覆盖到彩色背景时会留下丑陋的边缘,但对于卡通风格内容的短小循环动画,GIF 在普及程度上仍然胜出。

BMP(1990 年 5 月)与 TIFF(1986 年秋)，遗留的旧将

BMP(Bitmap,亦称 Windows Device Independent Bitmap)被并入 1990 年 5 月 22 日发布的 Windows 3.0,在那里成为 Windows 图形环境中位图存储的标准。它本质上是未压缩的，原始像素数组,可选地按行对齐到 4 字节边界,前面有一个小标题。一张 1920×1080、24 位的 BMP 大约 6.2 MB;同一张图作为质量 85 的 JPEG 可能只有 200 KB。BMP 在 2026 年的角色,本质上是一种遗留的交换格式,也是 Windows 截图历史上使用的格式。TIFF(Tagged Image File Format)由 Aldus 公司于 1986 年秋首次发布(版本 3.0);1992 年 6 月的版本 6.0 增加了 CMYK 与 YCbCr 颜色以及 JPEG-in-TIFF。Adobe 于 1994 年收购 Aldus,目前持有版权。TIFF 的独特之处在于,它是一个容器格式,而不是单一的编码方案，一个 TIFF 文件可以保存多张图像(多页 TIFF,常见于传真和扫描的书籍章节),使用多种压缩方法之一(无、LZW、ZIP、JPEG、用于传真的 CCITT Group 3/4),并通过其带标签的字段结构存储几乎任意的元数据。这种灵活性让 TIFF 成为印前流程、扫描和文档归档的默认格式;它基本上从未用于 Web 图像。它出现在输入列表里,是为了把面向印刷的或扫描来的源文件转换成 Web 友好格式的用户准备的。

WebP(2010 年 9 月 30 日)，现代 Web 格式

Google 于 2010 年 9 月 30 日发布 WebP,作为面向 Web 的有损压缩真彩色图形的新开放格式,在可比质量下产生比 JPEG 更小的文件。该格式基于 VP8 视频编解码器的关键帧编码,而 VP8 是 Google 通过收购 On2 Technologies 获得的。一开始 WebP 仅支持有损。2011 年 11 月 18 日,Google 宣布在无损与有损两种模式下都增加无损压缩模式与透明度支持;libwebp 0.2.0 于 2012 年 8 月 16 日达到稳定的无损实现。按照 Google 的开发者文档:无损 WebP 图像比同样图像的 PNG 小约 26%,有损 WebP 图像在等价 SSIM 质量下比可比的 JPEG 小 25-34%。这些缩减并不是魔法，它们来自一个根本上更新的编解码器设计(预测式帧内编码、现代算术熵编码、更聪明的颜色变换),相对于 JPEG 与 PNG 当年面对的 1990 年代初基线而言。浏览器支持是慢慢建立起来的:Chrome 17(2012 年 2 月,有损)、Chrome 23(2012 年 11 月,无损)。Apple 顶住了将近十年,最终在 Safari 14 中加入 WebP 支持,Safari 14 与 iOS 14 和 macOS 11 Big Sur 一起在 2020 年 9 月发布。2020 年 9 月这个日期,就是 WebP 在不需要为 iPhone 用户保留 JPEG 兜底的情况下,真正可以作为主用 Web 格式的时刻。今天的覆盖率约为全球流量的 97%，WebP 不再是带保留意见的「现代」格式,它已是默认。

WebP 之后:AVIF(2019 年 2 月)、HEIC(2017)、JPEG XL(2018-)

AVIF v1.0.0 于 2019 年 2 月 19 日由 Alliance for Open Media(AOMedia,由 Google、Netflix、Microsoft、Mozilla、Cisco、Intel、Amazon、Apple 组成的联盟)发布。它是 AV1 视频编解码器的静态图像配置,基于 HEIF 容器,目前是部署最广而且压缩最好的图像格式，在等价视觉质量下,AVIF 文件通常比 JPEG 小 50%、比 WebP 小 20-30%。浏览器支持分三波到来:Chrome 85(2020 年 8 月)、Firefox 93(2021 年 10 月)、Safari with iOS 16(2022 年 9 月)和 macOS Ventura(2022 年 10 月)。HEIC 自 2017 年的 iOS 11 起是 iPhone 默认格式，HEIF 容器搭载 HEVC 压缩的图像,正式编号 ISO/IEC 23008-12。压缩极为出色(通常比 JPEG 小 50%),但 HEVC 受专利束缚,这就是 Chrome、Firefox 与非 Apple 的 Edge 拒绝原生解码 HEIC 的原因。JPEG XL(ISO/IEC 18181,2022)是技术上极优秀的小众格式，它能把现有 JPEG 无损重压缩到约小 20%,支持 HDR、广色域、动画与渐进解码,并且无专利。Chrome 在 2022 年 10 月 31 日撤掉了它的实验性开关(「万圣节决定」);Apple 于 2023 年 9 月发布 Safari 17,在 macOS Sonoma、iOS 17 与 visionOS 上原生支持 JPEG XL。该格式在 Safari 17+ 中原生支持,在 Firefox 与 Chrome 145(2026 年 2 月)中位于开关之后,但默认面向一般流量发布仍待定。本转换器目前不输出 AVIF、HEIC 或 JPEG XL，它们列在这里,是为了让你决定是否在上游处理它们。

选择正确的输出格式

上面那段格式逐个走的历史是巡礼。实用的问题更短:给定一张特定的图像和特定的用途,哪种输出格式才是对的?

• 带平滑渐变的照片(人物、食物、风景、产品照):JPEG 仍然是最大兼容性下的安全答案,质量取 75-85。WebP 在同样的视觉质量下会小 25-34%,在 97% 的浏览器中都被支持。
• 线条画、带文字的截图、徽标、图表、插画:PNG 是默认。这类图像特征性的硬边与大片纯色区域,正是 JPEG 处理得最差的内容，DCT 振铃伪影会涂抹边缘,让文字看起来发毛。WebP 无损在相同内容下大约比 PNG 小 26%。
• 博客文章的 Web 优化:WebP 是新内容的新默认;如果你的受众需要,可以为遗留流量配上 JPEG 兜底。
• 社交媒体变体:大多数平台无论你上传什么都会再编码,所以源格式不如源分辨率与质量来得重要。把 4000×4000 的 PNG 上传到 Instagram 相比上传一个 1080×1080 的 JPEG-质量-90 在画质上没有任何收益，Instagram 会在内部对两者都重新采样和重新压缩。
• 归档格式归一化:PNG(无损)用于图形,TIFF 用于下游工作流期望 TIFF 的印前与扫描归档。长期归档要避开 WebP 与 AVIF，两者都还年轻,数十年后解码器的可用性,无法像对 JPEG 与 PNG 那样有把握地假定。
• iPhone 导出:把 HEIC 转成 JPEG 以求最大兼容性,转成 WebP 用于 Web,转成 AVIF 给最前沿的网站。HEIC 周围的授权复杂性,正是「HEIC 转其它任何东西」的转换器有用的原因。

质量滑块到底在做什么

质量滑块以 5 为步长从 10 走到 100。这一个数字背后,是一种感知质量与文件大小之间出人意料的非线性关系。对于 JPEG,图像处理工程界的共识是:质量 75-85 是甜蜜区。在质量 80,从未压缩源到最终文件大小下降 70-90%,而在正常屏幕观看距离下视觉差异不可察觉。质量 80 与 85 之间的下落很陡:一张代表性测试图可能从质量 80 时的 3.7 MB 跳到质量 85 时的 6 MB,几乎翻倍,而在手机或笔记本屏幕上看不到任何改善。质量 75 是开始能在仔细观察高频细节(文字边缘、细密纹理)时察觉到伪影的位置。质量 90 及以上是为档案级 JPEG 准备的,那种情形下文件大小已经不重要。默认 80 落在甜蜜区的低端，适合批量 Web 优化,目标是在保持图像看起来可接受的前提下,尽量少送出数据。对于 WebP,canvas API 的 toBlob('image/webp') 默认是质量 0.80;质量 70 的 WebP 在视觉上一般和质量 80 的 JPEG 一样干净。对于 PNG,「质量」是一种用词不当，PNG 在像素数据上始终是无损的。当选择 PNG 作为输出格式时,本工具的滑块没有效果。批处理的关键教训:对于一个混合批次里的每一张图,单一的质量设置很少是对的。一个文件夹里 50 张同一台相机、同一光线下拍的照片,可能可以全部以 JPEG 质量 80 保存而不损失。一个混合了截图、照片、线条画与徽标的文件夹则不行，一键「全部转 JPG-80」会把截图变成无法阅读的蚊子噪声。当内容多样时,把输入分成不同的批次。

有损 vs 无损，最重要的区别

无损编码器保证解码输出与编码输入按位完全一致。PNG 是无损的。WebP-无损是无损的。TIFF(在其无损模式下)是无损的。代价是文件大小:无损编码器无法利用难以察觉的感知差异,必须保留所有信息。一张 1920×1080 的照片作为无损 PNG 可能是 5 MB;同一张照片作为 JPEG 质量 85 是 200 KB。PNG 是按位完美的;JPEG 是视觉上等价的。有损编码器丢弃人类视觉系统最不可能注意到的信息，高频细节、饱和色彩中的细微色度差异、每个渐变里的第四位有效数字。JPEG、有损 WebP 和有损 AVIF 都在做这件事。这对一个批量转换器有具体的含义:无损到无损(PNG 到 PNG,或 PNG 到 WebP-无损)在任何次数的转换之间都是真正无损的;同质量的有损到有损(JPEG-85 到 JPEG-85)不是无损，每一次重新编码都会再施加一次量化,重复 10 次结果就明显劣化;有损到无损(JPEG 到 PNG)把已有的伪影定格,但不会再次劣化它们;无损到有损则在转换的瞬间引入有损压缩,被丢弃的细节之后无从恢复。用户经常重新跑一次转换,期望它是个 no-op。除了无损到无损这种情况,它都不是。

EXIF、IPTC、XMP，以及为什么本工具把它们剥掉

来自相机和手机的 JPEG 与 HEIC 文件携带一个 EXIF 块，嵌入在图像头里的 Exchangeable Image File Format 元数据。EXIF 包含相机型号、镜头、曝光设置、日期与时间、软件版本,而最要紧的是拍摄地点的 GPS 坐标(如果拍摄时定位服务是开着的)。IPTC 元数据加上说明、署名、版权和关键词。XMP 最初来自 Adobe,是基于 XML 的超集,涵盖了较旧的格式,Lightroom 和 Photoshop 使用的就是它。隐私上的影响很大。一张在开着定位的 iPhone 上拍下的照片,会嵌入精确到几米以内的 GPS 坐标。把它分享到论坛、作为邮件附件,或贴到个人博客上,可能就泄露了摄影者的家庭住址、孩子的学校、工作场所、徒步路线。主要的社交平台(Facebook、Instagram、Twitter/X)在上传时会先剥掉 EXIF,再把图像发给其他用户（但他们自己会读取并存储原始元数据。较小的论坛、WordPress 博客、Discord、邮件客户端和直接的文件传输,都会让 EXIF 原样保留。通过 canvas API 重新编码(本工具用的就是它),会默认丢弃所有的 EXIF、IPTC 与 XMP 元数据。输出是一张没有嵌入出处的干净图像）这是一项隐私特性,也是 canvas 流水线的副作用(canvas 只存像素数据,它对要保留什么元数据没有概念)。想要保留元数据的用户(归档曝光数据的摄影师、要求版权随文件流转的内容工作流)需要不同的工具，典型的有 ImageMagick 的 convert 或专门的 EXIF-感知库。本转换器朝着另一个方向切:它在设计上就是「剥元数据」,这正是注重隐私的用户在向不希望 GPS 坐标随之而去的论坛发图时所想要的。

透明背景，PNG 转 JPEG 的抉择

PNG 支持逐像素的 alpha 通道:每个像素都有从 0(完全透明)到 255(完全不透明)的不透明度。JPEG 没有 alpha 通道。把带透明的 PNG 转成 JPEG 就强制做出一个选择:那些透明像素该变成什么?canvas API 的默认行为是与透明黑合成,因此最终得到的 JPEG 会把透明像素解析成不透明的黑色。一个透明背景上的 logo 在 PNG 转 JPEG 后,会带着围绕 logo 的黑色边角出来（几乎从来不是用户想要的结果。缓解办法是在画图之前先用一种选定的背景色填满画布(白色是常见默认)。需要保留透明度的用户应当选择 PNG 或 WebP 作为输出格式。WebP 在无损与有损两种模式下都支持透明度,这让它在「源带透明、目标需要高效」的情况下成为现代选择）一张 50 KB 的透明背景 PNG 可能变成一张 12 KB 的透明背景有损 WebP,同时保留 alpha 通道。

转换在你的浏览器里如何运行

「一切都在你的浏览器里跑」这个说法,依赖于直到最近才足够强大、能让批量图像转换器作为客户端产品成立的三个 Web 平台API。FileReader 与 Blob API:当你把文件拖进上传区,每个 File 都是 Blob 的子类,暴露 readAsDataURL()(较老的回调式)或 file.arrayBuffer()(基于 Promise)。具体到图像,更简单的路径是用 URL.createObjectURL(file) 构造一个 Blob URL,然后把它赋值给一个新的 Image 元素,让浏览器内置的图像解码器原生地处理 JPEG、PNG、GIF、WebP 与 BMP。Canvas API:一旦 Image 加载完成,转换就是一支两步舞，先用 ctx.drawImage(img, 0, 0) 画上去,再用 canvas.toBlob(callback, type, quality) 把 canvas 读回来。type 参数是 MIME 字符串('image/png'、'image/jpeg'、'image/webp');quality 参数对有损格式来说是 0 到 1 之间的数。OffscreenCanvas 与 Web Workers:对于大批量,把全部 canvas 工作放在主线程上会阻塞 UI。现代解法是 OffscreenCanvas,它把 canvas 操作暴露在 worker 上下文中,本身又可通过 postMessage 转交给一个 Web Worker 而不需要拷贝。worker 在另一个线程里跑「解码-栅格化-编码」流水线,让页面保持响应。这些 API 加在一起,让一批 50 个文件能在数秒内跑完,不会卡住滚动或按钮点击。JSZip（一个纯 JavaScript、MIT 许可的库）在浏览器保存对话框弹出之前,完全在内存里完成最终的 ZIP 打包。没有上传、没有服务器端 zip、没有磁盘上的临时文件。十年前,一个跑在浏览器里的批量图像转换器本会是稀奇玩意儿。WebAssembly 性能、OffscreenCanvas 的并行,加上现代手机的内存(6-12 GB)与核心数(6-8 颗CPU),把这幅画面整个翻了过来。隐私论点把这个案子合上了:服务器端的转换器要求把你的图像上传到第三方机器,即便有再严格的删除策略,上传本身就是一次可被记录、拦截或泄露的网络事件。仅在浏览器里运行的转换器一个字节都不会送出去。

常见问题

支持哪些图片格式？

该转换器处理大多数常见格式（JPG、PNG、GIF、WebP、BMP、TIFF），并可转换为 PNG、JPG 或 WebP。

可以调整 JPG 和 WebP 的质量吗？

可以。使用质量滑块调整压缩（0–100）。数值越高，质量越好，但文件也越大。

如何下载多个文件？

选择「打包下载 ZIP」，将所有已转换的图片打包为一个 ZIP 压缩包，方便下载和存储。

为什么每批限 50 个文件?

这是内存上限。每张图都得先解码成内存里的原始像素,然后canvas 才能重新编码。一张 1200 万像素的 iPhone 照片解码后大约是 36 MB 的像素数据(1200 万像素 × 3 字节 RGB,或4 字节 RGBA)。一次 50 张就是 1.8 GB 的工作内存。多数笔记本可以从容应对;较老的手机不行。50 个文件这条上限,让页面在不同设备上都可预测。需要更大批次时,就把工具分轮运行，比如 50 个、下载、清空、再扔 50 个。

单个文件有大小限制吗?

没有硬性上限，上限是你设备的可用内存。一张 5000 万像素的图解码后大约是 150 MB 的像素数据,在桌面上可以,但在较老的手机上会吃力。一个经验法则:小于 10 MB 的文件在几乎任何设备上都能流畅转换;大于 50 MB 的文件在低端移动设备上会变慢或失败。如果一次转换卡住了,刷新一下页面,把这个文件放进更小的一批里再试。

转换器会剥掉 EXIF 元数据吗?

会，这是设计如此。canvas 重新编码流水线只存像素数据,所以 EXIF、IPTC 与 XMP 元数据块(相机型号、曝光设置、GPS 坐标、版权标签、编辑历史)都熬不过这一次往返。输出是一张没有嵌入出处的干净图,在你向论坛或邮件联系人分享照片、又不希望 GPS 坐标随之而去时,这是一种隐私收益。如果你需要保留元数据(归档曝光数据的摄影师、要求版权标签的内容工作流),那这就是错的工具，请用 ImageMagick 的 convert 或专门、明确保留元数据的 EXIF-感知库。

把 PNG 转成 JPG 时,透明背景会怎样?

JPEG 没有 alpha 通道,所以源 PNG 中的透明像素必须在 JPEG 输出里变成某种不透明颜色。canvas 的默认行为是与一种彩色背景(通常是白色)合成。一个透明 PNG 背景上的 logo 转成 JPEG 后会丢掉透明,继而带上背景填充色。如果透明很重要,选 PNG 或 WebP 作为输出格式，两者都保留 alpha。WebP-lossy 在比 PNG 小得多的文件尺寸下保留透明度,是透明 Web 图形的现代选择。

我的图像会被上传到任何地方吗?

不会。每一步（文件选择、解码、canvas 重新编码、ZIP 打包、下载）都完全通过 JavaScript 在你的浏览器里跑。没有服务器端处理。你可以在转换的同时打开浏览器 DevTools 的 Network 面板自行验证:没有任何携带图像数据的外发请求。这个页面对敏感截图、文档扫描、含定位元数据的私人照片,或其他你不想被复制到陌生人硬盘上的东西来说,都是安全的。

相关工具