Secure PDF Editor 開源 PDF 塗黑工具實測：本地處理的真相與兩種塗黑強度的差異

Facebook Line Messenger Telegram

把一份印有身分證字號的合約 PDF 寄出去之前，最怕的不是對方沒收到，而是黑條底下其實還有人讀得到。Secure PDF Editor 是一個打著「百分百本地、不上傳」旗號的開源 PDF 塗黑工具，我把它的 GitHub 專案 clone 下來讀了一遍原始碼，也實際打開官方示範站操作了一輪，想看清楚「本地處理」這四個字究竟站不站得住，以及它把敏感內容抹掉的程度，是不是如宣傳所說的那麼徹底。

這篇文章不重複官方行銷文案，而是從原始碼與實際操作出發，把 Secure PDF Editor 真正能做的事、說得比較滿的地方，以及不該交給它處理的情境，一次講清楚。如果你平常處理的是合約、發票、履歷、身分證件這類對外文件，又不想把檔案交給第三方雲端，它可以放進你的工具箱，但放的時候要先讀完下面這幾層。

把檔案拖進去之前，先看清楚「本地」這兩個字

Secure PDF Editor 的官方網站 secureredact.tech 在首頁寫著「100% Local Processing」「No server uploads」「Permanent Removal」，看起來是一個把隱私放在最前面的工具。專案本身在 GitHub 上是以 MIT 授權公開（repo：jyxwant/secure-pdf-editor），任何人都可以自己架一份。我打開示範站點下「Start Redacting」，畫面會停在一個相當乾淨的拖檔上傳區，沒有註冊牆、沒有信箱驗證，這部分跟宣稱一致。

Secure PDF Editor 官方示範站首頁，標題寫著 Redact PDFs Securely in Browser 與 100% local processing 主張。 — Secure PDF Editor 官方示範站首頁強調全程本地處理、無伺服器上傳。

不過，「本地」這兩個字在 PDF 工具的語境裡向來有兩層意思，一層是檔案內容不離開你的機器，另一層是整個網頁完全不發出任何網路請求。這兩件事常常被混在一起講，但對隱私的影響差很多。Secure PDF Editor 在第一層是站得住的（下面會用原始碼證明），但第二層就有一些但書，這也是這篇文章想把話說清楚的地方。

先把它的基本盤列出來，方便你判斷定位。Secure PDF Editor 是 GitHub 帳號 jyxwant（個人簡介寫武漢大學）的 side project，專案建立於 2025 年 8 月，最近一次推送是 2026 年 1 月，到本文截稿為止大約五個月沒有新 commit。截至 2026 年 7 月 7 日，星星 29 顆、fork 0、沒有 open issue、沒有發布過任何 release 版號，package.json 裡的作者欄寫的是「Claude Code」，也就是這個 codebase 是 AI 輔助 Scaffold 出來的。這些事實本身不是扣分項，但代表它是一個低活躍的個人專案，把它放進高強度工作流程之前，要先把這個前提放在心裡。

從原始碼看塗黑這件事是怎麼發生的

Secure PDF Editor 提供兩種塗黑方式，一種叫 Canvas 重繪（Canvas render），一種叫像素化（Pixelation）。兩種的實作邏輯直接寫在 src/hooks/usePDFProcessor.tsx 這個檔案裡，我讀完之後可以告訴你，它們處理 PDF 的徹底程度並不一樣，宣傳頁把兩者都包裝成「永久移除」，其實簡化了。

Canvas 重繪法的實作在第 299 行起的那個函式。它先用 pdf.js（pdfjs-dist）把原 PDF 每一頁渲染到一張離屏 canvas，把你在上面畫的紅框一併蓋掉，然後呼叫 offscreenCanvas.toBlob 把整頁變成一張 JPG 影像，再用 pdf-lib 的 newPdfDoc.embedJpg 把這張影像嵌進全新的 PDF。換句話說，輸出檔已經沒有原本的文字層，本來可以選的文字現在全部變成一張圖裡的像素，這也是它「強度高、難回推」的原因。代價同樣明確：檔案體積通常變大，沒塗到的地方也無法再用滑鼠選取複製。

像素化處理則寫在第 413 行起的另一個函式。同樣先用 pdf.js 渲染頁面，但只針對你標記的矩形區域做馬賽克處理（把區域縮小再放大，讓細節糊成色塊），沒畫到的地方保留原樣，最後整頁一樣轉成影像嵌回 PDF。它的優點是保留版面、保留可讀性，但這同時表示它的塗黑是視覺層級的遮蔽，不是資料層級的抹除。對高解析度原始影像做點分析，理論上有機會把馬賽克後的文字還原到可辨識的程度，這也是它被官方原始說明文件標為「適合中低風險場景」的原因。

這裡附一張實際打開示範站後的拖檔上傳畫面，你可以看到它的操作起點相當直覺，就是選檔、畫框、選方法、下載。

Secure PDF Editor 點下 Start Redacting 之後的拖檔上傳介面，中央有拖放區與選擇檔案按鈕。 — 點下 Start Redacting 之後進入的拖檔上傳介面，後續流程都在這個介面裡完成。

Canvas 重繪與像素化：哪一種才真的把字抹掉

兩種方法的差異如果只用文字描述會有點抽象，我把它們整理成下面這張比較表，重點擺在「塗黑強度」與「副作用」這兩個你真正會在意的維度。

維度	Canvas 重繪	像素化
輸出層性質	整頁變成影像 PDF	原頁面影像僅局部馬賽克
原始文字層	幾乎不再保留	未遮蔽處仍可見但已轉為影像
塗黑可逆性	難回推（已點陣化）	理論上高解析度可部分還原
檔案體積	通常變大	增幅較小
適合風險等級	高（合約、身分證、財務）	中低（試卷答案、草稿備註）

Canvas 重繪與像素化的處理徹底度並不相等，依文件風險等級選方法才是正確用法。

處理高敏感文件（合約、身分證、財務資料、病歷摘要）的時候，我會建議直接選 Canvas 重繪，並且在正式外發之前，先用一份非正式的測試檔跑過一次，確認輸出效果如預期。像素化留給那些「遮一下答案」「把草稿備註擋掉」這類就算被還原也無傷大雅的場景。Secure PDF Editor 原始的中文說明文件其實也是這樣建議的，這點它誠實，只是首頁的「Permanent Removal」行銷文案把這層差異抹平了。

另外它還會在匯出階段做一份中繼資料清理，對應的程式碼在 usePDFProcessor.tsx 第 697 到 709 行，把 setTitle、setAuthor、setSubject 清空，setCreator 與 setProducer 改成應用程式名稱。這能擋掉一般檔案總管看得到的那層資訊，但要注意它處理的是 PDF 的 info dict，不是完整的 XMP 封包，少數較深的元資料欄位不一定被清乾淨。這是一份「盡力而為」的清理，不是鑑識等級的抹除。

「無網路請求」的說法要分兩層看

Secure PDF Editor 最強調的賣點是「不會把檔案上傳到伺服器」。這句話我讀完原始碼後可以幫它背書一半。我把整個塗黑處理路徑（src/hooks/、src/components/pdf/、src/workers/）掃了一遍，完全找不到任何 fetch、XMLHttpRequest、axios 或 WebSocket 呼叫，PDF 的位元組確實是在瀏覽器裡用 pdfjs-dist 解析、用 pdf-lib 重新組裝，再由 html2canvas 與 jspdf 在本機完成渲染與匯出。檔案上傳區用的是標準的 <input type="file" accept=".pdf,application/pdf">，選了檔案之後直接進記憶體，沒有走網路。所以「你的 PDF 內容不會離開瀏覽器」這件事，在程式碼層級是成立的。

但「無網路請求」這個更強的說法，就不完全準確了。Secure PDF Editor 的網站是用 Next.js 部署在 Vercel 上的（這裡也順便校正一下，它的 README 還寫著 Vite 6 與 5173 port，但 package.json 實際上是 Next.js 14，npm run dev 跑起來是 port 3000，說明文件並沒有跟上程式碼演進）。在 src/app/layout.tsx 第 3 行與第 4 行，它引入了 @vercel/analytics 與 @vercel/speed-insights，第 79 行還有一行 <link rel="preconnect" href="https://vitals.vercel-analytics.com" />，第 93 行則渲染了 <SpeedInsights scriptSrc="https://secureredact.tech/_vercel/speed-insights/script.js" />。也就是說，網站會把頁面瀏覽計數與效能指標回報給 Vercel 的遙測服務。

這裡要講得很精準才公平：這些遙測回報的是「有沒有人來訪、頁面載入花了多久」這類流量與效能資料，不包含你正在處理的 PDF 內容。所以對「我的檔案會不會被上傳」這個問題，答案是不會；但對「這個網站會不會發出任何網路請求」這個更嚴格的問題，答案是其實會，只是回報的不是你的檔案。如果你很在意連流量統計都不能有，那就只能走下面會講的自己架一份這條路，把分析模組拿掉。同樣的「宣稱沒有後端，其實有遙測」校正邏輯，之前我們在 Text2Voice 文字轉語音工具那篇也示範過，差別在於 Text2Voice 是真的有後端 API 外送文字，而 Secure PDF Editor 只到流量分析這層，沒有碰檔案內容，兩者的嚴重程度不同。

自己架一份的真相：README 跟 package.json 對不上

Secure PDF Editor 是 MIT 授權，你可以合法地自己架一份。原始的中文介紹把它說得很輕，大概就是 clone、npm install、npm run dev 三個指令。我實際看 package.json 與 next.config.mjs，部署門檻確實不高，但有兩個小坑要先講。

第一個是前面提到的文件過時問題。README 寫的是 Vite 6，指令也建議你開 http://localhost:5173，但專案實際上已經重構成 Next.js 14（next dev 預設 port 3000），同時引入了以路由為基礎的多語系結構（src/app/[lang]/）、blog 系統與 SEO 中繼資料管理。對一個只想在本機跑塗黑功能的人來說，這些多出來的東西是噪音；對想把原始碼讀懂的人來說，文件跟程式碼不同步會讓你繞一圈。

第二個是授權與商用的邊界。Secure PDF Editor 本身的 LICENSE 是乾淨的 MIT，商用改作都允許，但專案裡引用的 pdfjs-dist 是 Apache 2.0、pdf-lib 是 MIT，這些依賴的授權條款要一併遵守（多半是保留版權聲明就好，負擔不大）。如果你打算把它包進自家產品或內部工具，做一次依賴清單的授權盤點是負責任的做法，而不是假設「主專案 MIT 就等於全部乾淨」。

哪些檔案別用這把刀

Secure PDF Editor 不是萬用塗黑機，它有幾個硬限制。單檔上限大約 50MB，超過會吃力；不支援有密碼、有加密的 PDF，這類檔案你得先解密才能處理（而解密這件事本身就可能違反檔案來源的使用條款，要自己把關）；沒有批次流水線，只能一份一份手動處理，遇到成百上千份文件的企業場景就別考慮它；處理速度也直接取決於你本機的 CPU 與記憶體，老舊機器跑大檔會卡。

還有一件事要提醒。Secure PDF Editor 的網站頁尾放著「About Us」「Privacy Policy」「Terms of Service」三個連結，但我實測 secureredact.tech/privacy、/terms、/about 三個路徑全部回 404。換句話說，它對外宣稱「符合 GDPR、HIPAA」，卻連一份可以讓你查閱的隱私政策或服務條款都沒有。這是一種條款真空的狀態：工具本身或許真的能幫你降低合規風險，但「使用這個網站」這件事並沒有任何條款在規範。如果你是法務或 IT 部門要在公司內部導入，這點一定要寫進評估報告，不能只看首頁的合規字眼。

順著這個脈絡回答三個最常被問的問題，讓你更容易判斷它放不放得進你的流程。

它跟 Privacy Filter 這類本機脫敏工具差在哪

我們之前介紹過 Privacy Filter 這個把文字丟給 AI 前先在瀏覽器本機脫敏的工具，定位是「文字流的 PII 清理」，處理的是你要貼進 ChatGPT、Claude 的 prompt。Secure PDF Editor 處理的則是已經成型的 PDF 檔案，對象是文件版面裡的區塊。兩個都是本機優先路線，但分工不同：一個守文字輸入端，一個守檔案輸出端。如果你同時有這兩種需求，把它們想成前後兩道過濾網會更清楚。

它跟 AvePDF 這類線上 PDF 套件比起來

如果你對「檔案要不要上傳」沒有那麼在意，AvePDF 這類完整的線上 PDF 工具套件功能廣得多，轉檔、合併、OCR、壓縮都有，但代價是檔案必須先離開你的設備，送上他們的伺服器處理。Secure PDF Editor 走的是相反方向：只做塗黑這一件事，但堅持把檔案留在瀏覽器。這是一個典型的「功能廣度 vs 資料控制度」取捨，沒有誰絕對好，看你手上那份文件的敏感等級決定。

極機密文件能不能交給它

不能。極機密等級（例如涉及營業秘密、個人特種資料、尚未公開的財報）的文件，不應該過任何一個瀏覽器工具，包括 Secure PDF Editor。它適合「日常對外文件送出前的那一層遮蔽」，而不是鑑識等級的銷毀。真正極機密的場景，請回到實體隔離環境或內部專業流程，這也是 Secure PDF Editor 原始說明文件自己也標註的免責聲明。

放在它真正能勝任的位置

講完這幾層，Secure PDF Editor 的輪廓其實相當清楚。它是一個把一件重要的小事做得還不錯的工具：在瀏覽器裡、不把檔案交給第三方、用兩種強度不同的方法把 PDF 上不該外流的內容遮掉。對於發票、合約、履歷、身分證件這類日常等級的對外文件，它足以取代你過去那套「截圖再貼黑條」或「找個線上工具賭一把」的流程，而且因為是 MIT 開源，你可以自己架在內網當作團隊參考方案。

但它的限制跟它的強項一樣明確。README 跟實際程式碼對不上、首頁的合規字眼背後沒有法律頁面撐腰、「無網路請求」的說法要扣除 Vercel 遙測這層、像素化不能拿來處理高敏感內容、沒有批次也沒有加密檔支援。這些不是用它來否定這個工具，恰恰相反，知道它邊界在哪，才能安心用它處理邊界以內的事。

如果你今天的需求是「偶爾要把幾份對外文件上的敏感資訊遮掉，又不想把檔案上傳給陌生伺服器」，Secure PDF Editor 是一個值得放進書籤的選擇。如果你要的是企業級文件治理、批次脫敏、審計留痕，那它還不到那個位置，請往專業商業方案走。先列一份你平常會外發的文件清單，標出哪些是日常等級、哪些是極機密等級，再決定要不要把 Secure PDF Editor 放進流程，會比盲目信任任何「百分百安全」的宣傳更穩當。

本文方法論

本文基於截至 2026 年 7 月 7 日的 GitHub 專案 jyxwant/secure-pdf-editor（版本 1.0.0，package.json 標註，最近一次 git push 為 2026 年 1 月 30 日，未發布過 release 版號）+ 官方示範站 secureredact.tech 實測 + 原始碼關鍵檔分析（含網路呼叫審計）。第一手元素：clone 後讀 src/hooks/usePDFProcessor.tsx 塗黑邏輯（Canvas 重繪第 299 行起、像素化第 413 行起、中繼資料清理第 697 至 709 行）、掃 src/hooks 與 src/components/pdf 與 src/workers 確認塗黑路徑無任何 fetch/XHR/WebSocket、追 src/app/layout.tsx 揭露 Vercel Analytics 與 Speed Insights 遙測、打開示範站點下 Start Redacting 進入拖檔介面、並查驗 /privacy、/terms、/about 三條法律頁面皆回傳 404。未涵蓋：長期使用、生產環境壓力測試、你的具體文件結構、以及 Playwright 自動操作沒能完整跑完一次拖檔到匯出的紅框塗黑流程（介面只走到拖檔上傳區，未實際產出一份塗黑後的 PDF），這些需自行驗證。

來源頁 ahhhhhfs 第 79939 號文章因站方暫時無法連線（HTTP 522，原始伺服器不可達），本文以 Wayback Machine 2026 年 4 月 8 日快照對照其報導角度與已知限制，並以 live GitHub 專案與示範站現況為準。截稿前再次探測 ahhhhhfs 仍無法連線。

如果你對這類「本機優先」路線的工具感興趣，也可以回頭看我們寫過的純前端音訊轉文字工具，那篇同樣在拆解「宣稱本機」與「實際資料流向」之間的落差，兩篇對照著讀會更理解這條路線的取捨。