工具
指南

gzip / deflate / zlib 压缩与解压

编码

使用 gzip、deflate 或 zlib 压缩/解压文本，输出 Base64 或十六进制，并对比压缩前后体积。

100% 客户端 无后端

不获取远程 URL；请直接粘贴你的 JSON。

方向
输入
输出
输入要压缩的文本，或粘贴 Base64/十六进制以解压。
本页内容

什么是 gzip 压缩？#

gzip 是 Web 上通用的无损文本与字节压缩器——HTTP 的 Content-Encoding: gzip、你从服务器拉下来的 .gz 文件、无数日志采集器的传输格式，背后都是它。它的原理是找到重复的字节模式、用短引用替代，所以有重复的文本（源代码、JSON、CSV、日志行）能大幅缩小，而已经压缩过或随机的数据（JPEG、加密字节）几乎纹丝不动。

本工具提供口语里被笼统叫作”gzip”的三种相关算法，它们只是在同一个 DEFLATE 内核外裹了不同的壳：

  • gzip（RFC 1952）——完整套装：带魔数字节的头、压缩后的载荷、外加 CRC32 和原始大小的尾。.gz 文件和 HTTP gzip 用的就是它。
  • deflate（RFC 1951）——没有任何外壳的原始压缩流。输出最小，但没有完整性校验；有些 API（老式 Content-Encoding: deflate）要的正好是它。
  • zlib（RFC 1950）——一个 2 字节的轻量头加一个 Adler-32 校验和，介于两者之间。

因为压缩输出是二进制的，工具会把它渲染成 Base64 或 Hex 文本，方便你复制、粘进 JSON、或者接到别处。解压是逆操作：读入 Base64 或 Hex，还原出原始 UTF-8 文本。

怎么使用#

  1. 在工具栏选 算法（algo）：gzip、deflate 或 zlib。
  2. 选 方向（dir）：压缩（compress，文本进 → Base64/Hex 出）或 解压（decompress，Base64/Hex 进 → 文本出）。
  3. 选 输出编码（out）：Base64 或 Hex（解压方向下此选择器锁定，因为工具会自动识别编码）。
  4. 在左侧 输入 框粘贴，输入框头里显示输入大小；结果填进右侧 输出 框，头部同样显示大小。
  5. 压缩完成后会出现 前后对比条，告诉你载荷是变大了还是变小了。点 复制（Copy）取走结果，或点 下载（Download）存成 .gz 文件。示例（Sample）载入一条典型日志行，清空（Clear）重置一切。

主要特性#

  • 三种算法，一个控件。 在 gzip、deflate、zlib 之间切换，直观看到同一输入下”外壳开销”如何改变输出大小。
  • 诚实的体积对比。 前后对比条给出真实的字节数和带正负号的百分比变化——包括”压缩反而变大”这种情况，而这恰恰是关于 gzip 最该知道的一件事。
  • 解压自动识别编码。 粘 Base64 或 Hex 都行，工具自己判断，你不必记。
  • 反向严格 UTF-8。 如果解压出来的字节不是合法 UTF-8（选错了算法、载荷被截断），工具会明说，而不是吐出替换字符把错误盖住。
  • 浏览器内运行。 压缩靠一个延迟加载的小库在本地完成，你粘贴的内容不会离开本页。

实例演示#

把一条短日志行——示例 输入 2026-08-06 INFO request handled path=/api/stats status=200（58 字节）——用 gzip + Base64 压缩，得到：

H4sIAHcNdmoAAzMyMDLTNbDQNTBT8PRz81coSi0sTS0uUchIzEvJSU1RKEgsybDVTyzI1C8uSSwpVgCRpcW2RgYGACs/7EA6AAAA

前后对比条会暴露出反直觉的那一面：这 58 字节的纯文本，gzip 再 Base64 之后变成了 75 字节。输入太短、也太随机，DEFLATE 找不到东西可压，于是 gzip 的头、尾和 Base64 那 33% 的膨胀就纯粹叠加上去。这正是为什么对微小载荷做 gzip 没有意义。

对比一下重复文本。把 transaction_id=txn_00001 status=paid amount=100 currency=usd\n 这一行复制 8 份，共 488 字节，gzip 把它压到 84 字节——大约是原来的 17%。这才是压缩发光的地方：重复越多，缩得越狠。

同一条短日志切到 deflate，输出降到 57 字节（无头尾）；zlib 落在 63 字节——当你瞄准某种特定线上格式、需要和对面严丝合缝对齐时，这很有用。

常见问题#

gzip、deflate 还是 zlib，到底选哪个？#

跟着对面走。.gz 文件、HTTP Content-Encoding: gzip、几乎所有”压缩过”的 API 载荷，都用 gzip。只有当某个 API 明确写明要原始 DEFLATE 时（一些老的 Content-Encoding: deflate 服务端）才用 deflate。当某个库或协议指名道姓时再用 zlib。拿不准时，gzip 是最稳妥的默认。

输出比输入还大，是 bug 吗？#

不是——这是无损压缩作用于”小体积或高熵”输入时的正常表现。每个流都有固定开销（头、尾、字典预热），如果内容几乎没重复，DEFLATE 拿不回这笔成本。一个实用经验：载荷到几百字节以上、尤其是带重复的文本时，gzip 才稳定地赚回来。对很小的值，跳过压缩。

解压报”不是合法 UTF-8”，是哪里错了？#

通常是三种情况之一：选错了算法（数据其实是 zlib 压的但你选了 gzip，或反过来）、Base64/Hex 被截断或中间夹了空白、或者原始内容本来就是二进制而非文本。挨个试试别的算法，再检查粘贴的载荷有没有被哪里截短。

这个工具能压缩图片、视频或已经压缩过的文件吗？#

能粘，但基本压不动。JPEG、PNG、MP4、以及 .zip/.gz 本身已经是压缩过的，DEFLATE 无利可图——输出要么差不多大、要么略大。gzip 是给文本和结构化数据用的，不是给二进制媒体做二次压缩的。