手機掃描的合同發給對方
掃描 App 導出的 20 頁合同有 40 MB,郵件附件超限。平衡檔壓縮後約 5–6 MB,屏幕閲讀無差別;對方若需打印,打印檔約 12 MB 也在多數郵箱限制內。
使用指南
PDF 壓縮把文件的每一頁在瀏覽器裏渲染成一張位圖,按你選的清晰度重新編碼為 JPEG,再把這些 JPEG 拼回一份頁面尺寸不變的新 PDF——文件不上傳,結果通常只有原件的幾分之一到幾十分之一。
更新於 2026-09-094 个来源约 12 分钟读完
PDF 壓縮把文件的每一頁在瀏覽器裏渲染成一張位圖,按你選的清晰度重新編碼為 JPEG,再把這些 JPEG 拼回一份頁面尺寸不變的新 PDF——文件不上傳,結果通常只有原件的幾分之一到幾十分之一。
它最適合的對象是掃描件和以圖片為主的文件:手機掃描 App 生成的 PDF、複印機直出的合同、相機拍的票據。這類文件每頁本來就是一張大圖,重新按合理的分辨率和質量編碼,體積往往能減少 70% 以上,而屏幕上幾乎看不出差別。
它不適合以文字為主、體積本就不大的文件。整頁圖像化意味着原本幾 KB 的矢量文字會變成一張一兩百 KB 的圖片,文件不但不會變小,還會失去「可選中、可搜索、可複製」的特性。工具面板裏的黃色提示説的正是這件事,本文原理一節會解釋為什麼。
三個檔位對應三組固定參數:屏幕(72 DPI,JPEG 質量 0.55)、平衡(110 DPI,0.70,默認)、打印(150 DPI,0.82)。壓縮前先決定文件的去處——發微信看用屏幕檔,存檔兼顧打印用平衡或打印檔——比事後反覆試更省時間。
scan_压缩_省87%.pdf;若輸出比原件還大,文件名裏就沒有「省」字——這是在提醒你這份文件不適合圖像化壓縮。結果卡可「再次下載」或「加入工作區繼續處理」。一份 6 頁的掃描件,每頁是 2480×3508 像素(相當於 A4 紙 300 DPI)的 JPEG,原件 2.41 MB。三個檔位的實際結果:
檔位 渲染分辨率 每頁像素 每頁 JPEG 6 頁合計 節省
屏幕 72 DPI · 質量 0.55 595×841 ≈ 20 KB 120 KB 95%
平衡 110 DPI · 質量 0.70 909×1286 ≈ 51 KB 302 KB 87%
打印 150 DPI · 質量 0.82 1240×1753 ≈ 109 KB 642 KB 73%
作為對照,一份 12 頁、只有矢量文字的合同(11.7 KB)用平衡檔壓縮後變成 1.65 MB——每頁都成了一張約 137 KB 的圖片,文字也不再能選中。

PDF 本身已經是一種壓縮格式:文字用字體輪廓描述,圖片內部通常已是 JPEG 或 Flate 壓縮。所謂「PDF 壓縮」在不同工具裏可能指三類完全不同的事:
本工具採用第 3 種。理解這一點,就能預判它在什麼文件上有效、在什麼文件上適得其反。
PDF 的頁面尺寸用**點(pt)**度量,1 pt = 1/72 英寸,A4 紙是 595.28 × 841.89 pt。渲染時工具用 pdf.js 把頁面畫到畫布上,縮放比例是 DPI ÷ 72:
這一步是重採樣:原掃描件如果是 300 DPI,輸出 110 DPI 就丟掉了約 87% 的像素((110/300)² ≈ 0.13)。像素少了,JPEG 編碼前的數據就少了,這是體積下降的第一個來源,也是不可逆的。
渲染時頁面上的所有元素——文字、矢量圖形、圖片、批註外觀——都被合成到同一張位圖裏,背景鋪成白色(JPEG 不支持透明)。
位圖隨後經瀏覽器的 JPEG 編碼器編碼,質量參數(0–1)來自畫布的 toBlob() 接口。JPEG 把圖像切成 8×8 的塊,做離散餘弦變換後按量化表捨棄高頻細節:質量越低,量化步長越大,保留的高頻越少,文件越小,邊緣附近的「振鈴」與塊狀偽影越明顯。
三檔的質量值 0.55 / 0.70 / 0.82 是為「掃描文字仍可讀」調過的:低於 0.5 時筆畫邊緣會出現明顯噪點,高於 0.85 後體積增長很快而肉眼收益很小。編碼細節(是否做色度抽樣、用哪套量化表)由瀏覽器決定,因此同一檔位在不同瀏覽器裏輸出體積可能相差一兩成。
一頁矢量文字在 PDF 裏的成本是:字體一次性嵌入(幾十 KB,全文檔共用)+ 每個字符幾個字節的定位指令。一頁 A4 密排文字可能只有 2–5 KB。
同一頁圖像化後,110 DPI 就是 1.17 兆像素。文字邊緣是 JPEG 最不擅長的高頻內容,即使質量 0.7 也要 100–150 KB 才能把黑白邊緣編得像樣。於是 12 頁合同從 11.7 KB 漲到 1.65 MB,漲幅超過 100 倍。這不是 bug,是圖像化方法的固有性質:它只在「原件每頁本來就是一張更大的圖」時才有收益。
輸出是一個全新的 PDF:每頁一個與原頁視覺尺寸相同的空頁,上面鋪一張覆蓋整頁的 JPEG(PDF 裏叫 DCTDecode 濾鏡的圖像對象)。原文件的字體、矢量、文本層、書籤、表單、鏈接、元數據都不會進入新文件。在工作台裏插入的空白頁保持為矢量空頁,不會被圖像化;掃描件裏原有的空白頁則和其他頁一樣會被渲染成圖片。
因為新文件是純圖片,任何 PDF 閲讀器都能打開,兼容性極好;但「查找」功能會一無所獲,屏幕朗讀器也讀不到任何文字。
掃描 App 導出的 20 頁合同有 40 MB,郵件附件超限。平衡檔壓縮後約 5–6 MB,屏幕閲讀無差別;對方若需打印,打印檔約 12 MB 也在多數郵箱限制內。
幾十張發票拍照生成的 PDF 只需留檔備查。屏幕檔能把體積壓到原來的 5% 左右,文字仍可辨認。
網申系統要求單個附件不超過 5 MB,而學歷證明掃描件有 18 MB。選平衡檔,若仍超限再試屏幕檔;最後核對文件名裏的節省比例。
老師把掃描版講義發到班級羣,學生大多在手機上看。屏幕檔壓縮後加載快、流量省;需要打印的同學可以另取原件。
因為原文件以矢量文字為主,本來就很小。圖像化會把每頁變成一張一兩百 KB 的圖片。這類文件不需要壓縮;若確實要減小體積,問題往往出在幾張內嵌大圖上,請用「PDF 提取圖片」檢查。
先想清楚去向:只在屏幕上看選屏幕檔;不確定就選平衡檔;可能打印選打印檔。三檔之間體積大致是 1 : 2.5 : 5,清晰度隨之遞增。
不會。新文件每頁的尺寸與原頁(含你在工作台裏做的旋轉)完全一致,只是內容變成了圖片。
目前壓縮作用於當前文件的全部頁面。可以先用「PDF 拆分」把需要壓縮的部分分出來,壓縮後再「PDF 合併」回去。
不能直接恢復。圖像化是不可逆的。如果需要文字,只能對壓縮件做 OCR,識別精度取決於檔位——屏幕檔的 72 DPI 對 OCR 來説通常太低。
每頁都要渲染成大位圖再編碼,頁數多、原件分辨率高時耗時明顯;手機上尤甚。可以先用「PDF 拆分」分段處理,或換到桌面瀏覽器。
壓縮的每一步——用 pdf.js 渲染頁面、用畫布編碼 JPEG、用 pdf-lib 重建文件——都在你的瀏覽器裏進行,文件不會上傳到任何服務器。中間產生的位圖只存在於內存,關閉頁面後釋放。斷網狀態下同樣可用。
HTMLCanvasElement.toBlob()——quality 參數的定義與取值範圍:https://developer.mozilla.org/zh-CN/docs/Web/API/HTMLCanvasElement/toBlob(访问日期:2026-09-08)getViewport({ scale }) 語義(scale = 1 對應 72 DPI):https://mozilla.github.io/pdf.js/(访问日期:2026-09-08)更新於 2026-09-09
圖像化重編碼減小體積,屏幕 / 平衡 / 打印三檔
所有處理均在你的瀏覽器本地完成,文件不會上傳到任何服務器