离线 · 无上传 · 浏览器本地完成Offline · no uploads · runs in the browser
Markdown 转 WebP——离线、A4 分页逐页编码、不上传Markdown to WebP offline — A4 pages, no upload
三步，最后一步换成 WebP：`md>html` 用 marked 按 GFM 渲染（管道符表格、删除线、任务清单、自动链接都被认出；段落里单个换行仍是续行），过 DOMPurify 的 html + svg 两套 profile（**文档里的内联 SVG 图形不会被删**），再套上自带的样式表；`html>pdf` 把这份文档整篇渲染成一张画布、按 A4 比例算页数并切成同高片段，每片段以无损位图（PNG）嵌进 PDF；`pdf>webp` 再逐页转成 WebP。因此产物形状与 Markdown→JPG、HTML→WebP 完全一致：一页一图、两页以上以 ZIP 交付（成员名 `page-N.webp`）、单页直接给一个 `.webp`；WebP 与 JPEG 同属有损容器，质量与目标体积这两格对它们生效，追逐顺序是先降质量、再缩尺寸。与 JPG 那格唯一的实质区别就是终点容器；本项目没在本机做过两套体积对照，所以这里不宣称谁更小——同一份文件各跑一次比字节数，比任何保证可靠。要说清的边界：中间那份 PDF 转图时这一格不摆密度滑杆（面板只对以 PDF 为输入的转换给它），但存储里的密度值会随每一步带走，没设过时是默认 144；整页捕获高度上限 32768 px，超过明确报错；图里没有可复制的文字；**Markdown 里以网络地址或相邻路径引用的图片取不到字节**——渲染前剥掉引用、结果卡按张数披露，被替换的位置画虚线方框，只在克隆那一步失败的那种直接留空。脚本不执行、全程离线，只有 storage 权限。Three steps, the last one WebP: `md>html` renders through marked as GFM (pipe tables, strikethrough, task lists and autolinks are recognised; a single newline inside a paragraph stays a soft wrap), passes DOMPurify’s html and svg profiles — **so an inline SVG diagram is not deleted** — and is wrapped in the bundled stylesheet; `html>pdf` renders that document into one canvas, computes the page count from the A4 ratio, slices it into equal-height strips and embeds each losslessly as PNG; `pdf>webp` then encodes every page as WebP. The artifact shape is therefore identical to Markdown to JPG and HTML to WebP: one image per page, a ZIP from two pages up with members named `page-N.webp`, a single `.webp` for one page. WebP and JPEG are the two lossy containers, so quality and a target size apply here, chased by lowering quality first and scaling afterwards. The only substantive difference from the JPEG page is the final container; this project has run no same-file size comparison between the two on this machine, so neither is claimed to be smaller — convert your own file twice and compare byte counts. The boundaries: this route exposes no density slider (the panel offers it only for conversions taking a PDF as input) while a stored density is forwarded to every step and defaults to 144 when unset; the whole-page capture is bounded at 32768 px of height and fails past it rather than trimming; there is no copyable text in the image; and **images the Markdown points at by network address or sibling path have no bytes** — the references are stripped before rendering, the count is disclosed on the card, a replaced spot becomes a dashed box, and one that fails only during cloning is left blank. No scripts run, everything is offline, and the only permission is storage.
这条链路怎么走How the route runs
MarkdownMarkdown HTMLHTML PDFPDF WebPWebP
共 3 步，由扩展的路径搜索自动选出，中间产物不落盘。3 steps, chosen by the extension's own path search; intermediate results never touch the disk.
会保留什么What carries over
- 语法变成排版：标题、列表、任务清单与表格按 GFM 渲染后再进图Syntax becomes layout: headings, lists, task lists and tables render as GFM before imaging
- 内联 SVG 图形保留：净化同时挂 html 与 svg 两套 profileInline SVG diagrams survive: sanitising runs the html and svg profiles together
- 一页一图且切片无损：片段以 PNG 进 PDF，压缩只在最后转 WebP 那一次发生One image per page with lossless slices: strips enter the PDF as PNG, so compression happens once, on the final WebP
- 质量与目标体积在这条路上是真档位（与 JPEG 同为有损容器）Quality and target size are real dials here, the same lossy container class as JPEG
如实说明的限制What it does not do
- 有损：目标体积先降质量、再缩尺寸，所以「文件小了」有两种来路Lossy: a target size lowers quality before it scales the picture, so “smaller” has two causes
- 引用的图片取不到字节：远程与相邻路径的引用被剥掉，位置是虚线方框或空着，卡片按张数披露Referenced images have no bytes: remote and sibling references are stripped, a spot is a dashed box or blank, and the card reports the count
- 这一格不摆密度滑杆；存储里留下的密度值仍会被带到中间那份 PDF 那一步This route exposes no density slider, yet a density left in storage still reaches the intermediate PDF step
- 整页捕获高度上限 32768 px，超过报错而不是交付半张图A 32768 px ceiling on the whole-page capture height, failing rather than trimming
- 一次最多渲染 200 页（`MAX_PDF_IMAGE_PAGES`）：超过就报「要渲染的页数过多」，并让你用页码范围只选需要的页或先把文件拆开——每一页在编码前各自占着一张全尺寸画布，200 页已经是数百 MB，再往前是标签页自己崩掉，那比一条错误难说清得多At most 200 pages rasterise in one pass (`MAX_PDF_IMAGE_PAGES`): past that the route reports “too many pages to render at once” and points at a page range or splitting the file — every page holds a full-size canvas until it is encoded, 200 of them is already hundreds of megabytes, and beyond that the tab crashes itself, which is far harder to explain than an error
- 图里没有可复制的文字，也不承诺能读回 Markdown：要编辑请保留 `.md`No copyable text inside the image and no promise of reading Markdown back out: keep the `.md`
实操提示Working with it
- 要严格无损的版面：Markdown→PNG（整页一张长图）或 Markdown→PDF（一份文档）For an exactly-lossless layout: Markdown to PNG (one tall image) or Markdown to PDF (one document)
- 要一页一页对照体积：同一份文件分别走 Markdown→JPG 与 Markdown→WebP，比字节数To compare sizes page by page: run the same file through Markdown to JPG and Markdown to WebP and compare byte counts
- 要给程序读的数据：Markdown→HTML / CSV / JSON，这一格交付的是版面For data a program reads: Markdown to HTML, CSV or JSON — this page delivers the layout
常见问题Questions people actually ask
Markdown 转 WebP 和转 JPG 有什么不同？How is WebP different from JPEG here?
前两步完全相同（GFM 渲染成同一份带样式表的 HTML，再切成同样的无损 A4 片段），只有终点容器不同：一个交 WebP、一个交 JPEG，两者都有损、都支持质量与目标体积。谁更小本项目没在本机量过，不做宣称——用你自己的文件各跑一次比字节数最可靠。The first two steps are identical — GFM into the same styled HTML, sliced into the same lossless A4 pages — and only the final container differs. Both ends are lossy and both take quality and a target size. Which compresses smaller has not been measured here, so nothing is claimed; run your own file through both and compare byte counts.
我的表格会变成什么？What happens to my tables?
管道符表格经 marked 变成真正的 `<table>`，自带样式表给它 100% 宽、每格 1px 实线、表头浅底与偶数行条纹，然后这一切被拍进图里。产物是位图：格子里的值不能再被选中或编辑，列宽由排版决定而不是由源文件的竖线数量决定。A pipe table becomes a real `<table>` through marked, and the bundled stylesheet gives it full width, a 1px rule per cell, a tinted header and striped even rows — all of which is then imaged. The artifact is a bitmap: values cannot be selected or edited, and column widths come from layout, not from the number of bars in the source.
为什么转换报错说「渲染高度过大」？Why did it fail with “too tall to render”?
整篇文档是一次性渲染成一张画布的，那条路径的高度上限是 32768 px（一边最大 8192 px 的四倍）。这条链宁可报错也不交空白或被截短的结果——远超这个高度时浏览器给的其实是画不出内容的空白画布，那种「成功但全白」比一条错误难查得多。要处理这么长的文档，请把它拆开，或者改走 Markdown→PDF 那样的分页产物。The document is rendered into one canvas, and that path is bounded at 32768 px of height (four times the 8192 px edge ceiling). The route prefers failing over returning blank or trimmed output, because well past that height a browser hands back a canvas that draws nothing — a white “success” much harder to diagnose than an error. Split the document, or take the paged Markdown to PDF artifact instead.
不需要账号，也不需要联网：装好扩展后点图标，在新标签页里打开工作台，文件从磁盘直接选。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.