压缩视频，全程不上传

「不上传」到底差在哪

网上几乎所有免费视频压缩工具都是上传型的。你把文件交给一台自己控制不了的服务器，它在别人的文件后面排队，处理完再让你下载。这套模式能用，但代价不小：你的素材被复制到了别人的磁盘上，保留多久取决于隐私政策怎么写，而且一个 400 MB 的片子得先爬完你的上行带宽，才轮到开始处理。

这个工具反过来做。浏览器直接从磁盘读取文件，通过 WebCodecs API 把帧交给你设备自己的视频编码器，再把新的 MP4 边编码边写回本地。全程没有任何东西过网络——你可以在压缩时打开浏览器的网络面板确认，或者在页面加载完之后断网，照样能压。

由此带来两个实际差别。一是速度取决于你的硬件而不是上行带宽，所以短片几秒就完事。二是没有什么需要限流的：没有每日额度、不用排队、不用注册、没有水印，因为背后没有一台需要摊销成本的服务器。

本地压缩唯一做不到的，是在没有视频编码器的浏览器里运行。如果你的浏览器不受支持，上面的工具会直接说明，而不是偷偷退回上传。

大文件怎么压：为什么这里没有体积上限

浏览器里压视频，翻车通常都翻在大文件上，原因是内存。这类工具最直接的写法是把压好的视频先在内存里攒成一整个，攒完了才交给你——于是一个任务需要的内存会随着它自己产物的大小一起长。一段长录像最后要的内存可能比机器能腾出来的还多，标签页就死在中途。这也是浏览器端压缩工具通常都要挂一个最大文件体积的原因。

这个工具不是这么做的。压好的每一段都在编码完的那一刻就写进浏览器的本地存储，所以视频再长，内存占用也是平的。这一点是实测过的：把一段 40 分钟的 1080p 录像压成 500 MB，内存峰值 643 MB，从头到尾一条直线；同一个任务改成在内存里攒产物，峰值 1246 MB，而且压到结束还在往上爬。这个差别就是这里没有体积上限的全部理由。

取代体积上限的，是一道不会让你措手不及的检查。开始编码之前，工具会先估算产物有多大，再和浏览器实际可用的存储比一比。放不下就当场告诉你，而不是让你等四十分钟才发现。半成品也不会留下：中途取消或者关掉标签页，写了一半的文件会被删掉。

真正的天花板是你自己的可用磁盘空间，不是我们随手定的一个数字。几个 GB 的源文件没问题——两小时的视频是耐心问题，不是容量问题。

怎么在浏览器里压缩视频

整个过程三步，不需要任何设置——默认的 720p 就是大多数人想要的。

1. 选一个视频，或者把它拖到上面的框里。文件在本地读取，时长、分辨率和体积会立刻显示出来。
2. 选画质档位。720p 看起来最接近原片；540p 是按聊天软件的尺寸来的；360p 压得最狠。目标分辨率会在你确认前就显示出来。
3. 点开始压缩然后等。进度是真实的，不是估算的。完成后能看到前后体积对比，点下载保存新文件。

压缩是单向的——丢掉的细节找不回来。在你看过压缩后的效果并满意之前，先留着原文件。

该选哪一档

每一档都会把视频的短边缩到一个目标值，并限制平均码率。之所以按短边而不是宽度算，是为了让手机拍的竖屏视频和相机拍的横屏视频得到同样的处理。

任何情况下都不会放大。如果你把一个 720p 的视频丢进 720p 档，分辨率会原样保留，只有码率变化——这一点值得知道，因为这种情况省下的空间会比 4K 源少得多。

这三档和这三个码率与 Photo Slim 在 iPhone 上用的完全一致，所以同一个片子在这里压和在 App 里压，结果是一样的。

怎么把视频压到 10 MB、25 MB 或 100 MB

有时候要的不是「小一点」，而是一个数字：上传表单超过 25 MB 就不收，聊天软件卡在 10 MB，某个门户的上限是 100 MB。把工具从画质档位切到目标体积，你交给它的就是这个数字。它用预算除以视频时长得到码率，扣掉音频要占的那一份，再挑一档这个码率撑得住的分辨率——于是 720p、540p 还是 360p 不用你反复试，它替你定。

它刻意瞄得比目标略低，而不是正好压到，因为压出 25.4 MB 和压出 60 MB 一样会被拒。有两条边界值得先知道。音频轨是原样拷贝的，它在预算里占掉固定的一块，任何画质设置都抢不回来。另外，视频长到一定程度，小目标就不再是画质问题而是根本做不到——四十分钟的录像不可能变成一个还能看的 10 MB 文件。真遇到这种情况，工具会在你开始之前就说清楚，而不是花掉你的时间去压出一坨马赛克。

因为瞄的是「低于目标」而不是「等于目标」，无论对方按 1000 还是 1024 千字节算一兆，结果都能过线。

到底能压小多少

这几乎完全取决于源文件是什么，任何承诺固定百分比的工具都是在猜。省下的空间来自两处：降分辨率和降码率。如果你的源在这两项上都远高于目标，缩减会非常可观；如果本来就接近，能拿走的就不多了。

三个实测数字能把范围说清楚。一段 9 秒、96 Mbps 的 4K 片子，在 720p 档下从 105 MB 压到 2 MB——不到原来的 2%，因为它的源码率对这个时长来说高得离谱。一段 121 秒的 1080p 视频从 101 MB 压到 25 MB，约四分之一。而一段本身就是 720p 的 150 秒片子只从 95 MB 压到 37 MB，约 39%，因为分辨率根本降不下去。

规律很一致：高码率的手机原片、屏幕录像、以及任何 4K 素材，压缩效果都极其明显。而已经被压过一轮的视频——比如从聊天软件下载的片子——能再挤出来的很少，再压一次主要是在损失画质而不是省体积。

浏览器支持情况

这个工具需要 WebCodecs API 和一个可用的 H.264 视频编码器。当前版本的 Chrome、Edge 及其他 Chromium 内核浏览器，以及 Safari 18 及以上版本都具备这个组合。Firefox 目前还没有开放 WebCodecs 视频编码器，所以工具会检测出来并告诉你，而不是压到一半才失败。

能力检测在页面加载时就完成，不是等你点按钮才做，所以在选文件之前你就会知道结果。

开始前值得知道的限制

这是个单文件工具，边界在哪就说在哪。提前讲清楚，比压到一半才发现有用得多。

1. 一次一个文件。没有批量队列——要处理整个相册，App 才是对的工具。
2. 没有固定的体积上限，但有一道存储检查。天花板是你自己的可用磁盘空间，而且在开始编码前就测，不会让你压到一半才发现。
3. 目标体积是尽力达成，不是保证。选 10、25 或 100 MB，码率会从这个数字反推出来并刻意瞄低一点——但音频原样拷贝，在预算里占掉固定的一块；视频长到一定程度，小目标在任何画质下都塞不进去。这一点会在你开始之前告诉你，而不是压完才说。
4. 音频是直接拷贝的，不重新编码。原声轨会逐位保留，包括 5.1 环绕声——这也意味着音频对体积缩减没有任何贡献。
5. 输出固定是 MP4（默认 H.264，也可以开 HEVC）。这里没有格式转换、导出 GIF、剪辑或加水印。
6. 很长的视频仍然要等一会儿。在有硬件编码的桌面设备上我们实测是十到十七倍于实时——10 分钟的视频约一分钟出结果——手机上会慢得多。

这里做的任何操作都不会动你磁盘上的原文件。压缩后的是一个单独下载的副本，要不要删原件永远是你自己明确的决定。

常见问题