HyperFrames 图片压缩
把截图、看板、HyperFrames 导出图先压小，再发给团队或发布出去。
浏览器本地处理，保护隐私
所有处理都在浏览器里完成，不上传服务器。
HyperFrames 图片压缩
把截图、看板、HyperFrames 导出图先压小，再发给团队或发布出去。
拖入文件或点击浏览
80%
等待文件中
先添加一个文件再开始。
原始大小
-
输出大小
-
已保存
-
所有处理都在浏览器里完成，不上传服务器。
原始大小
等待文件中
输出大小
等待文件中
小提示
- 70-80 的质量通常已经够发文档和评审。
- 超大截图可以顺手限制最大宽度，体积会更可控。
- 所有处理都留在你的浏览器里。
HyperFrames 图片压缩
这个页面需要把“浏览器本地压图”讲明白：它在 HyperFrames 素材准备和导出交付里怎么用、能调什么、为什么有损。
压缩过程在浏览器本地完成，这降低了上传风险；但本地处理本身仍然依赖设备、浏览器和本地环境的安全性。
适合什么场景
压图本质上是在解决 HyperFrames 输入和输出的交付、传输问题，不只是点一下按钮。
把截图、参考板、商品图先压小，再发给支持、文档或评审同事。
在上传或交付前先减轻文件体积，减少存储和带宽压力。
不打开桌面编辑器，也能快速把重文件压到更实用的范围。
支持输入与控制项
当前页面围绕常见图片输入和基础压缩控制项展开。
输入：本地图片文件。
控制：质量滑杆、最大宽度限制。
输出：本地压缩结果，可直接下载继续使用。
怎么用
把静态步骤补齐，页面才不只是一个前端小组件。
1
上传图片
先确认预览图正确，避免把不该压的源文件误处理。
2
调整质量和宽度
更在乎体积就继续降质量/宽度，更在乎细节就尽量保守一点。
3
执行压缩并对比
页面会展示原始大小、输出大小和估算节省比例。
4
下载并投入下游流程
把压缩后的文件继续带入文档、商品页或托管工作台流程。
限制与注意点
本地压图很好用，但不等于没有代价。
压得太狠会让文字、边缘和细节发糊。
特别大的源图仍然受浏览器内存限制。
压缩只能减体积，不能把质量差的原图变好。
图片压缩 FAQ
直接回答压缩损耗、本地处理，以及进出 HyperFrames 工作台时什么时候该压图。
压缩后画面一定会变差吗？
通常会有一定损耗，只是损耗程度取决于你压得多狠，以及原图本身的内容。
进工作台前要不要先压图？
如果原图过大而且细节冗余很多，先压再传更合适；如果细节极其重要，优先保留原图。
这个页面是不是只有 HyperFrames 用户才需要？
不是。它本身就是独立可用的浏览器工具，只是同时也服务于站内的 HyperFrames 工作流。
相关页面
格式先不对时，先转格式，再继续压缩。
当参考图需要更稳定地进入多模态工作流时，先把体积和格式整理干净。
查看 HyperFrames 为谁服务，以及这些本地浏览器工具如何放进整体工作流。
查看哪些使用方式会被视为滥用、违规或超出站内允许边界。
了解提示词、上传内容、输出结果和反滥用审查是如何处理的。
看清 HyperFrames 和上游模型、第三方厂商之间的边界关系。