离线 · 无上传 · 浏览器本地完成Offline · no uploads · runs in the browser
Word 转 WebP——离线、中间真的过一份 PDFWord to WebP offline — it really passes through a PDF
这条路最不显然的地方是**它中间真的产出一份 PDF**：`docx>html` + `html>pdf` + `pdf>webp`（三步，路径基线现读）。第一步由 mammoth 把文档体还原成语义 HTML——标题层级、列表、表格，以及**内嵌图片读成的 data URI**；第二步把那份 HTML 按 **A4 纵向**交给浏览器排版，逐页渲染成画布、`toDataURL` 出 **PNG 无损切片**再 `addImage` 写进 PDF（那一步选的压缩档是 `SLOW`，即 zlib 加 PNG predictor，图省事会白花 CPU 或白花字节）；第三步用 pdf.js 把每一页画到**铺了白底的画布**上，编成 WebP。这条链的好处就藏在这个顺序里：**只有最后一次编码是有损的**——中间那一趟写的是 PNG 切片、不做第二次有损编码（整页仍按 800 版心与密度档重画一遍，那是排版带来的，不是压缩带来的），所以不会叠加代际损失，质量参数只在终点生效。要说清的代价有三条。分页**由浏览器排版决定**：Word 自己的页面设置、分栏与手动分页在这里没有对应物，想要 Word 认的那套分页，请在 Word 里导出 PDF 再走 PDF→WebP。多页的产出是 **ZIP**，条目名是 `page-N.webp`，而那个 N 是**这份文档的页号**。页数有上限：文档过长会在渲染那一步明确报「长度超出上限」而不是静默给你前几张。全程只有 storage 权限、不联网；产物里也没有任何远程引用需要取数——内嵌图片在第一步就已经是本地字节。The least obvious thing about this route is that **it really does produce a PDF in the middle**: `docx>html` + `html>pdf` + `pdf>webp` — three steps, read live from the route baseline. Step one has mammoth turn the document body into semantic HTML: heading levels, lists, tables, and **embedded pictures read out as data URIs**. Step two hands that HTML to the browser laid out as **A4 portrait**, renders each page to a canvas, and writes it into the PDF as **lossless PNG slices** via `toDataURL` and `addImage` (the compression setting picked there is `SLOW` — zlib plus a PNG predictor, a trade of encode CPU for bytes). Step three uses pdf.js to draw each page onto a **white-filled canvas** and encodes it as WebP. The advantage of that order is exactly where it hides: **only the final encode is lossy** — nothing in the middle runs a second lossy pass — the page is redrawn once at the 800 measure and a density tier, which is layout rather than compression, so generations do not stack up, and the quality setting applies at the end. Three costs to state. Pagination is **the browser’s layout**: Word’s own page setup, columns and manual breaks have no counterpart here, so if you need Word’s pagination, export a PDF in Word and take PDF to WebP from there. A multi-page result is a **ZIP** whose entries are named `page-N.webp`, and that N is the **page number in the document** — it stays aligned to the original page even when only some pages are converted. Length is capped: an over-long document fails with a clear «too many pages» instead of quietly handing you the first few. All of it on the storage permission with no network, and the artifact needs no remote fetch — the pictures were already local bytes from step one.
这条链路怎么走How the route runs
Word (.docx)Word (.docx) HTMLHTML PDFPDF WebPWebP
共 3 步，由扩展的路径搜索自动选出，中间产物不落盘。3 steps, chosen by the extension's own path search; intermediate results never touch the disk.
会保留什么What carries over
- 中间那一趟不做第二次有损编码：HTML→PDF 写的是 PNG 无损切片；整页按 800 版心与密度档重画一遍，终点才量化一次The middle step runs no second lossy encode: HTML to PDF writes lossless PNG slices, the page being redrawn once at the 800 measure and a density tier, and the only quantisation happens at the endpoint
- 标题层级、列表与表格进图；内嵌图片由第一步读成 data URI，类型在 `png / jpeg / gif / webp / bmp / avif / ico` 之内才会随文档进图，白名单外的（TIFF、EMF、WMF）会换成占位框Heading levels, lists and tables reach the image; embedded pictures arrive as data URIs, but only those whose type is in the allow-list (`png / jpeg / gif / webp / bmp / avif / ico`) travel with the document — a TIFF, EMF or WMF becomes a placeholder box
- 多页出 ZIP，条目名 `page-N.webp` 的 N 是文档页号Multi-page output is a ZIP with entries named `page-N.webp`, where N is the document page number and stays aligned even for partial conversions
- 文档过长会在渲染那一步明确报「长度超出上限」，不静默截断An over-long document fails at the render step with a clear «longer than the browser can render in one pass» rather than silently returning the first few
- 一批最多 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
- 分页由浏览器排版决定：Word 的页面设置、分栏、手动分页与页眉页脚在这里没有对应物Pagination is the browser’s layout: Word’s page setup, columns, manual breaks and headers/footers have no counterpart here
- 终点是有损编码：WebP 一次量化，像素不再是文档里那份原始位图；要可再编辑请走 Word→HTML / MarkdownThe endpoint is lossy: one WebP quantisation, so the pixels are no longer the document’s originals — take Word to HTML or Markdown when you need to edit again
- 图里的文字是像素：选不中、搜不到；脚注会作为末尾列表进那份 HTML、插入修订按正文读出、文本框内容照常成段，只有批注不落Words in the image are pixels: unselectable and unsearchable; footnotes do reach the intermediate HTML as a trailing list, tracked insertions read as body text and text-box content becomes paragraphs — only comments are left out
- 质量与目标尺寸的开关只在有损终点起作用，改不动中间那一趟The quality and target-size controls only act on the lossy endpoint, not on the middle step
- 想要 Word 认的那套分页：先在 Word 里导出 PDF，再走 PDF→WebPWant Word’s own pagination: export a PDF in Word first, then take PDF to WebP
实操提示Working with it
- 要每页一张 JPG：Word→JPG 是同一条三步链，终点编码换成 JPEGFor one JPEG per page: Word to JPG is the same three-step chain with JPEG at the end
- 要一份多页文档：Word→PDF，中间那一步就是终点、PNG 切片无损For a multi-page document: Word to PDF, where the middle step becomes the destination and the PNG slices stay lossless
- 要结构与文字都留住：Word→HTML 或 Word→Markdown，那里图片仍是内联数据To keep structure and words: Word to HTML or Markdown, where pictures are still inline data
常见问题Questions people actually ask
为什么转一张图要先做成 PDF？Why make a PDF first just to get an image?
因为「文档变成几页画面」这件事需要一个排版者，而这条链选的排版者是浏览器：它把 HTML 排成 A4、逐页渲染成画布，再把每页作为 PNG 无损切片写进一份临时 PDF，最后由 pdf.js 逐页出图。好处是分页与渲染在同一套规则里完成，代价是 Word 自己的页面设置不会被沿用。Because turning a document into a stack of page images needs someone to lay it out, and this chain’s layout engine is the browser: it sets the HTML as A4, renders each page to a canvas, writes those pages into a temporary PDF as lossless PNG slices, and finally draws each page out again. The gain is that pagination and rendering follow one set of rules; the price is that Word’s own page setup is not carried over.
这样会不会被压缩两次、画质更差？Does the picture get compressed twice, so quality suffers?
中间那一趟不是有损的：HTML→PDF 写进去的是 PNG 切片（无损，只是压缩档位选了偏节省字节的那一档）。真正只保留一次的有损量化发生在终点 WebP。换句话说，这条链不会「JPEG 叠 JPEG」，但也确实只剩一次量化的余地——质量参数只在那一步生效。The middle trip is not lossy: HTML to PDF writes PNG slices — lossless, with a byte-saving compression level rather than a cheap one. The single lossy quantisation happens at the endpoint, in WebP. So this chain never stacks JPEG on JPEG, but there is exactly one quantisation left to control, and the quality setting applies only there.
多页文档转出来是一个文件还是一堆？Does a multi-page document come out as one file or many?
一页一个 WebP，多页时打包成 ZIP，条目叫 `page-1.webp`、`page-2.webp`……编号是文档页号，即使你只转其中几页也对得上。只有一页时直接给单个 `converted.webp`，不出 ZIP。文档过长会在渲染那一步明确报「长度超出上限」。One WebP per page, zipped when there are several: `page-1.webp`, `page-2.webp`…, numbered by document page so the names still match even for a partial conversion. A single page yields one `converted.webp` with no ZIP, and an over-long document fails clearly at the image step.
不需要账号，也不需要联网：装好扩展后点图标，在新标签页里打开工作台，文件从磁盘直接选。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.