离线 · 无上传 · 浏览器本地完成Offline · no uploads · runs in the browser
GIF 转 WebP——离线、取首帧、透明保留GIF to WebP offline — first frame, alpha kept
这一格有两条容易混的方向，先分开说。第一，**它会丢动画**：`gif>webp` 是一步（路径基线现读），走的是图片转图片那条通用管线——解码到画布、`drawImage` 只取一帧，再 `encodeCanvas` 编成 WebP，所以产物是**静帧**；界面上会给出那句固定的「只保留第一帧」提示（`lostFrames` 是个布尔判断，界面从不报具体帧数）。想要动画继续存在，得走不重编码的路：GIF→HTML 把标签内联进页面、GIF→Markdown 写成一行内联图片、GIF→Word 把字节作为包内媒体部件带走——三条都**不重新编码帧**，帧仍在文件里；至于能不能播、播成什么样子，由打开它的那一边决定。第二，**它不铺白底**：画布上那层 `#FFFFFF` 只在终点是 JPEG 时才画（`utils/converters/image-convert.ts:51-54` 的条件是终点 MIME 类型恰为 image/jpeg），WebP 有透明通道、不需要垫底，所以 GIF 里那一格透明会带着 alpha 进 WebP——这与 GIF→JPG 正好相反（那边先把透明合成成白色再编码）。能调的是输出参数里的最长边与目标尺寸：最长边只在超过时才缩、**不放大**，目标尺寸是有损格式才生效的旋钮，两者都在最后一次编码上起作用。像素之外的东西都不在取数范围：不 OCR、不读内容，产物里没有任何字符串来自对画面的理解。若你要的是「一张透明底的静态图」，这一路是对的；要动画留在文件里，回到上面那三条；要更小的静帧，试调质量与最长边。全程只有 storage 权限，不联网、不上传。Two directions get confused here, so separate them first. **Yes, the animation is lost**: `gif>webp` is one step (read live from the baseline) through the shared image-to-image pipeline — decode onto a canvas, `drawImage` keeps a single frame, then `encodeCanvas` writes WebP — so the artifact is a **still**, and the interface shows its fixed «first frame kept» notice (`lostFrames` is a boolean test; the interface never prints a frame count). To keep the animation, take a route that does not re-encode: GIF to HTML inlines the tag into a page, GIF to Markdown writes one inline image line, GIF to Word carries the bytes as a media part inside the package — none of them re-encodes frames, so every frame is still in the file, while whether it plays and how is up to whatever opens it. **No, this route does not paint a white ground**: that `#FFFFFF` fill happens only when the endpoint is JPEG — the condition at `utils/converters/image-convert.ts:51-54` is that the endpoint MIME type is exactly image/jpeg — and WebP has a transparency channel, so the GIF’s transparent pixels keep their alpha into the WebP, the opposite of GIF to JPG, which composites them onto white first. What you can adjust is in the output options: the longest edge only scales down, never up, and the target size is a lever that exists only for lossy formats; both act on that final encode. Nothing outside pixels is in scope — no OCR, no reading of content, and no string in the artifact comes from understanding the picture. Want a still with a transparent background, this is the route; want the frames to stay in the file, go back to those three pages; want a smaller still, tune quality and the longest edge. All of it on the storage permission: no network, no upload.
这条链路怎么走How the route runs
GIFGIF WebPWebP
共 1 步，由扩展的路径搜索自动选出，中间产物不落盘。1 step, chosen by the extension's own path search; intermediate results never touch the disk.
会保留什么What carries over
- 透明保留：终点不是 JPEG，所以画布不铺白底，alpha 跟着进 WebPTransparency kept: the endpoint is not JPEG, so no white ground is painted and the alpha rides into the WebP
- 最长边只缩不放：超过设定值才等比缩，小图不会被拉糊The longest edge only scales down, never up, so small pictures are not stretched
- 目标尺寸与质量作用在最后那一次编码上（有损格式才有的旋钮）Target size and quality act on that final encode — knobs that exist for lossy formats
- 会明确给出「只保留第一帧」的固定提示，不静默把动画变成静帧A fixed «first frame kept» notice is shown, rather than silently trading the animation for a still
- 一批最多 200 个文件、单个 100 MB，与其他路线共用同一道闸门Up to 200 files per batch and 100 MB each — the same gate every other route shares
如实说明的限制What it does not do
- 动画不保留：产物是单帧静图，要让帧仍在文件里请走 GIF→HTML / Markdown / Word（都不重编码，播放由读它的那一边决定）The animation does not survive: the artifact is one still frame — keep the frames in the file by taking GIF to HTML, Markdown or Word, none of which re-encode, while playback is up to whatever opens it
- 提示只说「只保留第一帧」，不报帧数——帧数是布尔判断，界面无处得知The notice says only «first frame kept» and never a count, because the check yields a boolean
- 有损编码：WebP 会量化一次，边缘与渐变处的细节请按目标尺寸与质量自己试A lossy encode: WebP quantises once, so edge and gradient detail is yours to tune via target size and quality
- 不 OCR、不读画面内容，也不改帧率或挑某一帧（本扩展没有选帧功能）No OCR, no reading of the picture, no frame-rate editing and no frame picking — this extension has no such feature
- 透明虽保留，但 GIF 本身是 1 位透明：半透明边缘不会因此变平滑Transparency survives, but GIF carries 1-bit alpha, so soft edges do not become smoother here
实操提示Working with it
- 要保住动画：GIF→HTML（或 GIF→Markdown、GIF→Word），那几条都不重编码，帧都留在文件里To keep the animation: GIF to HTML (or Markdown, or Word) — none of them re-encode, so every frame stays in the file
- 要白底静帧：GIF→JPG 会把透明合成到白底，通用性最好For a still on white: GIF to JPG composites transparency onto white and is the most universally accepted
- 要无损静帧：GIF→PNG 保留 alpha 且不量化，只是同样只剩首帧For a lossless still: GIF to PNG keeps alpha and skips quantisation, and also keeps just the first frame
常见问题Questions people actually ask
为什么结果说「只保留第一帧」却不告诉我丢了几帧？Why does the result say “first frame kept” without a frame count?
因为那个判断只回答「是不是动图」：走查 GIF 的块结构、数到第二个图像描述符就返回真，不为了报数把整份文件读完。界面上因此是一句固定提示，而不是「丢了 N 帧」。（另外：动图 WebP 与 APNG 的动画判断目前不在这条检查的范围内。）Because the check only answers «was this an animation»: it walks the GIF’s block structure and returns at the second image descriptor rather than reading the whole file to produce a number. So the interface shows a fixed notice instead of «N frames lost». (Related: animation detection for animated WebP and APNG is outside this check today.)
GIF 的透明背景会变白吗？Will my GIF’s transparent background turn white?
这一路不会——白底只在终点是 JPEG 时才铺。所以透明像素带着 alpha 进 WebP。反过来说 GIF 的透明是 1 位的，边缘不会有半透明的柔和过渡，这一点不会因为换格式而改善。要白底静帧请走 GIF→JPG，要无损静帧走 GIF→PNG。Not on this route — the white ground is painted only when the endpoint is JPEG, so transparent pixels ride into the WebP with their alpha. That said, GIF transparency is 1-bit, so edges gain no soft blending, and changing format does not fix that. For a still on white take GIF to JPG; for a lossless still, GIF to PNG.
怎样才能既小又保留动画？How do I keep the animation and still get smaller?
这条链做不到：会重编码出 WebP 的路线都只剩一帧，而保留帧的路线（GIF→HTML / Markdown / Word）是搬运、不做优化。要「又是动图又更小」得真正重编码动画帧，本扩展没有这个功能；能做的只有把源 GIF 本身先缩小、或者接受一帧静图。This chain cannot: every route that encodes a WebP keeps one frame, while the frame-preserving routes (GIF to HTML, Markdown, Word) carry bytes and do no optimisation. A smaller animated file needs a real animation re-encode, which this extension does not offer; all you can do is shrink the source GIF first, or accept a still.
不需要账号，也不需要联网：装好扩展后点图标，在新标签页里打开工作台，文件从磁盘直接选。No account and no network: install the extension, click its icon, and the workbench opens in a new tab reading straight off your disk.
从 Chrome 应用商店安装Install from the Chrome Web Store 安装步骤Install steps GitHub 源码Source on GitHub
要把它压到指定体积？Need it under a target size? The 图片压缩工具image compressor可以在浏览器里重编码 PNG / JPEG / WebP。 re-encodes PNG / JPEG / WebP in the browser.