一個壓縮過的 PDF 檔案，只有在實際儲存的位元組數已達到或低於你所輸入的 MB 數值時，才算符合目標大小，而 Compress PDF to Size 的下載按鈕正是以這項精確的測量結果作為開啟條件。不估算、不近似，也沒有「大約這個大小」的承諾——在你與輸出檔案之間的關卡，是對你輸入的目標進行逐位元組的比較。如果在嘗試完所有有限範圍內的重新壓縮設定後，候選檔案仍然超過目標大小，該工具就不會回傳檔案，並說明無法在安全情況下達成目標。
這件事之所以重要，是因為網路上大多數「壓縮 PDF 至指定大小」的承諾實際上都無法驗證。它們秀給你看一個較小的檔案，然後告訴你那「夠接近」你的目標，或者把一個 1.8 MB 的檔案四捨五入成 1 MB。當你的下游工作流程仰賴一個硬性上限——電子郵件附件的限制、上傳入口的容量限制、求職申請的檔案大小規定——你需要的是一個能夠確認結果、而不是猜測結果的方法。「只有成功才提供下載」這種做法是最乾淨的確認方式，因為產生檔案的同一段程式碼，就是測量它的同一段程式碼。
在壓縮之後，「檢查結果」實際上代表什麼
檢查 PDF 壓縮的結果包含三個具體部分：確認儲存的檔案已達到或低於你的目標大小、確認頁數沒有變更，以及確認內容仍然可用。大多數人只檢查第一項，因為那是限制條件所要求的。然而，只檢查第一項的方法並不完整，因為一個雖然變小、卻少掉一半頁面的壓縮 PDF，雖然技術上比較小，但對原本要處理的任務來說毫無用處。
Compress PDF to Size 在顯示下載連結之前會處理全部三項檢查。它先儲存一個候選檔案，測量實際的位元組長度，再與你的目標比較。如果位元組數已達到或低於目標，它會以 PDF 檢視器（PDF.js）重新開啟該候選檔案，確認頁數與原始檔案一致。只有在這之後，下載按鈕才會出現。對於一個雖然符合位元組目標、但已遺失頁面的候選檔案，該工具不會顯示下載連結；對於一個超過位元組目標的候選檔案，也不會顯示下載連結。
該工具如何在你的瀏覽器內部驗證結果
驗證作業完全在你的瀏覽器內進行，使用兩項網路標準。PDF.js 函式庫會將候選檔案讀回為 PDF，並回報其頁數。HTML 的 canvas.toBlob 方法則是用來產生重新壓縮過程中所需的候選 JPG 內容——這與瀏覽器用於圖片匯出的基礎機制相同，相關說明請參考 WHATWG Canvas toBlob 規格。PDF.js 本身的說明文件位於 Mozilla PDF.js API 參考手冊。
實際上這代表的是：你被要求下載的位元組，是實際測量過的位元組，而不是從來源檔案估算而來的位元組。系統會開啟來源 PDF，解碼符合資格的 JPG 圖片，再以固定的品質與最長邊設定檔重新編碼每一張，最後重建並儲存結果 PDF。接著會直接讀取儲存檔案的長度——也就是你的作業系統會回報的方式——並與目標比較。過程中沒有額外的「近似大小」步驟。
這也是為什麼該工具可以在無法達成目標時誠實地表示「沒有結果」。它並不是在無窮迴圈中嘗試隨機設定；而是依序執行一組有限範圍的四個品質/尺寸設定檔（0.70/1400、0.55/1000、0.40/800、0.30/600），直到某個候選檔案同時通過兩項檢查才停止。如果沒有任何一個通過，工具會告訴你這個方法無法達成目標，而不是把一個過大的檔案交給你，還聲稱它已被壓縮過。
在已檢查的結果中，什麼會改變、什麼會保持不變
一旦了解該工具願意修改 PDF 的哪些部分，驗證步驟就顯得更重要，因為這決定了檢查過的檔案是否仍符合用途。下方表格說明在有限範圍的重新壓縮中哪些部分會被動到、哪些部分是工具刻意保留的。
| 會改變的部分 | 保持不變的部分 |
|---|---|
| 符合資格的內嵌 JPG 串流（未遮罩的 DCTDecode DeviceRGB 或 DeviceGray，且不含解碼參數）會以作用中設定檔的品質重新編碼 | 頁面結構、頁數與頁面順序 |
| 符合資格 JPG 的最大影像尺寸會在需要時縮小至作用中設定檔的最長邊數值 | 可選取的文字、連結、表單與向量內容 |
| 不支援的影像物件會原封不動保留 | |
| 整頁不會被點陣化 | |
| 如果某個候選 JPG 比其原始串流還大，該影像會保持不動 |
實際上的重點是：驗證最後的頁數檢查並非與位元組檢查重複。一個以犧牲頁數為代價而達成的目標，仍然會通過位元組測試，因此才會特地重新以 PDF.js 開啟來排除這種情況。
將 PDF 壓縮到目標大小並驗證結果
驗證機制已內建於 Compress PDF to Size 的三步驟工作流程中，這代表你不需要在之後額外執行「檢查」工具——下載按鈕本身就是檢查。
- 選擇一個最多 25 MB 的本地 PDF 並載入工具。檔案會保留在你的瀏覽器內；檢查過程中不會有任何資料離開你的裝置。
- 輸入一個介於 0.1 MB 至 25 MB 之間、且小於來源檔案的目標。這個目標就是儲存檔案必須通過的精確上限。
- 選擇壓縮至目標大小。工具會執行其有限範圍的設定檔、儲存候選檔案、測量實際位元組數，並以 PDF.js 重新開啟每個通過的候選檔案以確認頁數。
- 留意下載連結是否出現。如果出現，代表儲存的檔案已同時通過位元組檢查與頁數檢查，你可以儲存它。如果連結沒有出現，工具會告訴你無法在安全情況下達成目標——你不會因為疏忽而誤下載到過大的結果。
因為驗證發生在產生檔案的同一輪執行中，你不需要開啟第二個工具、不需要在 Finder 或 Explorer 中比較檔案大小，也不需要猜測結果是否夠好。下載按鈕在建構上，就只有在兩項檢查都通過時才會顯示。
結果將無法通過檢查的情況
驗證步驟對無法達成目標的情況是誠實的，這些情況值得在開始之前就了解，才不會在一個無法達成的目標上浪費一次執行。
- 純文字型 PDF。如果你的檔案主要是可選取的文字，且沒有內嵌 JPG 圖片，就沒有符合資格的串流可以重新壓縮，有限範圍的設定檔也無法有意義地縮減檔案大小。
- 向量內容為主的文件。以向量物件儲存的繪圖、CAD 類型的匯出檔案與圖表不會受到 JPG 重新壓縮的影響，因此目標大小將無法達成。
- 由不支援的影像主導的 PDF。帶有遮罩、CMYK 色域、ICC 設定檔、解碼參數或非 DCT 壓縮格式的影像會被工具跳過並保持不動，這限制了檔案可縮減的程度。
- 在小來源檔案上設定過於積極的目標。要求把一個 1.2 MB 的掃描檔壓縮到 0.1 MB，已超出有限範圍的 JPG 重新壓縮能安全達到的縮減幅度，工具會直接說明。本機作業的限制為最多 80 張符合資格的影像，以及解碼影像合計不超過 100 百萬像素，因此超過這些上限的來源檔同樣無法完成任務。
相對地，一個由 JPG 照片組成的掃描型 PDF，則是該工具處理得最理想的情況：由於每頁的影像都是符合資格的 JPG，可以重新編碼為較低的品質與較小的最長邊，因此往往可以達成遠低於原始大小的目標。
如何自行確認儲存的檔案
即使使用的是「只有成功才提供下載」的工具，自己做最後的檢查仍然值得，特別是對那些講求逼真度的文件。以你慣用的 PDF 閱讀器開啟儲存的檔案，瀏覽幾頁以確認圖片在新品質下仍可接受，並在作業系統中確認檔案大小與工具回報的數值一致。該工具回報的是儲存檔案的實際位元組長度，因此你在檔案總管中看到的數值應該完全相符。
在確認結果之前請保留原始 PDF，並就你在意的特定項目對照壓縮版本與來源——例如最後一頁的標誌、合約中的細則、行銷素材中的色彩準確度。該工具會保留向量、文字、連結、表單與不支援的影像，但它並不做出通用的無損聲明；因此對於那些在意視覺差異的文件，多看一眼是便宜的保險。
關於相同工作流程的相關指引，壓縮後的 PDF 是否一定能達到你的目標大小？一文說明了何時目標可以達成；在將 PDF 壓縮至目標大小時如何避免錯誤一文則涵蓋了選擇目標時常見的陷阱。