一個完全在瀏覽器中執行的影像疊加工具，之所以在線上使用是安全的，原因在於所有來源影像都是在本地解碼、在你分頁內部的 canvas 上合成，並以 PNG 格式匯出，從未離開你的裝置。然而，這項安全性聲明只有在工具確實在用戶端執行所有解碼與合成動作、使用會在檔案變更或頁面關閉時撤銷的 ObjectURL，並且不會對你的影像位元組發起背景上傳、擷取或分析呼叫時才成立。如果某個工具要求你登入、將檔案傳送到遠端 API，或將中介 blob 儲存在 CDN 上，即使其行銷頁面宣稱「安全」，也無法達到這個標準。同樣的情況也適用於那些雖然在本地執行工作，但在記憶體中留下懸置物件 URL，或將你的像素複製到日誌端點的工具。本文將拆解區分真正本地影像疊加與暗中將你的照片傳送到別處的技術信號，然後逐步說明完整的工作流程，讓你在信任之前能驗證每一個步驟。
對線上影像疊加而言，「安全」代表什麼
對影像疊加工具而言，安全性其實是三個問題層層堆疊在一起。第一個是資料位置:當工具開啟時，你的影像位元組實際位於何處?第二個是處理模型:工具是在你的瀏覽器分頁中執行解碼與合成，還是將檔案送到後端再回傳結果?第三個是側通道(side channels):即使工作是在本地進行，工具是否暗中呼叫分析端點、日誌服務，或可能取得你檔案複本或位元組雜湊的 CDN?
完全在用戶端執行的工具，對第一個問題能回答「你的裝置」，對第二個回答「你的分頁」，對第三個回答「沒有任何會接觸你影像的東西」。《影像疊加》工具符合這個描述:不需要帳號、不會向伺服器擷取影像位元組、沒有搭 canvas 順風車的第三方分析呼叫。這就是為什麼基於瀏覽器的影像疊加通常可以放心使用，也正是為什麼與其照單全收，不如實際驗證這些宣稱。
線上影像工具的風險輪廓並非一致。標誌、徽章或迷因圖片的敏感性幾乎為零，因此即使是稍有瑕疵的工具通常也足以勝任這些工作。但掃描的護照、病歷、內部公司截圖，或是附在私人訊息中的顧客照片，情況就完全不同。對於這類輸入，唯一可接受的答案是檔案絕不離開分頁，沒有例外。本文其餘部分將說明能讓你判斷眼前是哪一類工具的技術信號。
瀏覽器端的疊加如何將檔案保留在你的裝置上
瀏覽器端的影像疊加透過一條小而明確的管線來完成工作。輸入檔案透過 File 參考讀取、以 createImageBitmap 或類似 API 解碼為原始像素緩衝區、依計畫座標繪製到 HTMLCanvasElement，再透過 canvas 的 toBlob 方法匯出。這些步驟中的每一個都能在分頁內部完成，不需要任何網路呼叫。將疊加影像放到基底 canvas 上的 drawImage 方法記載於 CanvasRenderingContext2D drawImage 參考文件，大多數「私密」影像工具依賴的也是這個基礎機制。
ObjectURL 是最多人忽略的部分。當瀏覽器將 File 轉為可用的影像來源時，會透過 URL.createObjectURL 產生一個 blob URL，該 URL 只在仍有參考指向它時存活。如果工具在你替換檔案、改變位置或關閉頁面時忘記呼叫 URL.revokeObjectURL，該 blob 在記憶體中可存留的時間就可能超出應有的範圍。《影像疊加》會在選取新的基底或疊加檔案、重新產生匯出，以及元件卸載時，撤銷先前的 ObjectURL，因此被替換的影像不會洩漏到陳舊的預覽或下載之中。
背景還有一套世代(generation)系統。每個檔案都繫結到一個任務 ID，並由一個獨立的渲染世代來追蹤點擊動作。解碼疊加影像不會使進行中的基底解碼失效;在渲染進行中變更疊加影像，也只會使該疊加的角色失效。掛載狀態守衛會在元件卸載後拒絕回呼，這代表即使 toBlob 回呼來得慢，也無法覆寫你已經離開的工具狀態。中介不透明度採用 globalAlpha 設定，在疊加繪製周圍套用一次後即還原，因此 PNG 或 WebP 中的透明像素會保持透明，基底影像也不會被淡化。這些機制都不會顯示在 UI 上，但合在一起，正是把「我們不上傳」從口號變成可強制執行契約的關鍵。
塑造安全行為的輸入與輸出限制
安全性不僅關乎位置，也關乎工具拒絕做哪些事。明確宣告的硬性限制是一項安全功能，因為它能預先告訴你，工具願意處理什麼、又會拒絕什麼。《影像疊加》事前公開其限制，並對超出限制的輸入予以拒絕，而不是默默截斷、降階或產出損毀的檔案。
| 限制 | 數值 | 存在的原因 |
|---|---|---|
| 接受的輸入格式 | JPEG、PNG、WebP | 維持解碼面最小;GIF、SVG、AVIF 明確排除在外 |
| 每個輸入的最大壓縮檔案大小 | 25 MiB (26,214,400 bytes) | 防止過大的 blob 拖慢瀏覽器 |
| 最大解碼邊長(寬或高) | 20,000 pixels | 防止極端長寬比撐爆 canvas 記憶體 |
| 每張影像的最大解碼像素預算 | 40,000,000 pixels | 即使小壓縮檔展開為巨大緩衝區，也能限制記憶體用量 |
| 輸出格式 | PNG(一律) | 需要保留基底與疊加的透明度 |
| 輸出像素尺寸 | 等於基底影像的自然寬度與高度 | 避免默默縮放或「符合螢幕」的意外 |
邊界行為與限制本身同等重要。剛好 25 MiB 的檔案會被接受;再多一個位元組就會產生可復原的錯誤，不會產出部分結果。20,000 像素邊長與 40,000,000 像素預算也適用相同規則。這種嚴格、公開的截斷，正是你期待安全工具該有的表現:當你跨越界線時，立刻就能知道，而不是拿到一個損壞的 PNG。
如何在瀏覽器中安全地疊加兩張影像
安全的瀏覽器端疊加完整工作流程簡短且可預期。每一步在按下載之前都是可逆的，任何時候都能替換任一來源檔案，而不會留下陳舊的像素。
- 選擇一張基底影像與一張疊加影像。兩者皆可為 JPG、PNG 或 WebP，且每個檔案不得超過 25 MiB。基底是結果將被繪製在其上的 canvas;疊加則是你想放到它上面的圖片。
- 為疊加挑選一個錨點:置中、左上、右上、左下或右下。錨點是預定位置，而不是自由拖曳。
- 將疊加縮放設定在 10% 到 200% 之間。縮放僅套用於疊加，並以疊加自身的自然寬度與高度為基準。在 100% 時，疊加以其原始大小繪製;在 50% 時，各邊長為一半;在 200% 時，各邊長為兩倍。
- 選擇 0% 到 100% 之間的不透明度。零代表疊加完全透明，仍會產出與基底同尺寸的 PNG;一百則採用疊加自身的 alpha 不變。中介值會將疊加的貢獻乘以所選的 global alpha。
- 建立合成結果。工具會清除 canvas、在 alpha 1 下繪製基底、儲存狀態、套用所選的疊加 alpha、依計畫座標繪製縮放後的疊加、然後還原狀態，並以基底影像的自然像素尺寸匯出 PNG。
- 檢視預覽，然後下載 PNG。編輯位置、縮放或不透明度時，會立即撤銷先前的結果 URL，因此不會意外下載到陳舊的匯出。
用一個具體例子把算式講清楚。假設你的基底是 1600×900，疊加是 800×500，並選擇置中錨點、50% 縮放。疊加會以 800 × 50/100 = 400 px 寬、500 × 50/100 = 250 px 高繪製。中心 x = (1600 − 400)/2 = 600，中心 y = (900 − 250)/2 = 325。匯出的 PNG 為 1600×900，疊加以原始大小的一半繪製於 (600, 325)。只要代入相同公式，你就能為任何其他縮放比例重做計算。如需深入了解同一條不上傳的管線，請參閱在不上傳檔案的前提下將一張影像疊加到另一張上的指南。
匯出 PNG 中哪些會保留、哪些不會
即使是完美的私密疊加，也無法保留原始檔案的每一項屬性。PNG 是唯一的輸出格式，因為基底與疊加都可能包含 alpha 通道，而 JPEG 無法表示透明度。這個選擇有其代價:PNG 檔案會比原始 JPEG 大，且 PNG 不像 JPEG 攜帶同一組中繼資料容器。
| 屬性 | 是否保留於匯出的 PNG? | 備註 |
|---|---|---|
| 基底影像像素尺寸 | 是 | 輸出寬度與高度永遠等於基底的自然尺寸 |
| 透明度(alpha) | 是 | PNG 支援 alpha，透明區域會保留 |
| 原始檔案格式 | 否 | 所有結果皆為 PNG，包括來自 JPEG 輸入的結果 |
| EXIF 或相機中繼資料 | 否 | 重新編碼不會保留 EXIF;若有需要請使用專用的 EXIF 編輯器 |
| GPS 座標 | 否 | 連同 EXIF 區塊一併去除 |
| 動畫影格 | 否 | 靜態影像疊加不處理動畫 GIF 或動畫 WebP |
| 嵌入文字或 ICC 色彩描述檔 | 否 | 輸出為重新渲染的像素緩衝區，並非中繼資料直通 |
| 縮放時的銳利邊緣 | 部分 | 在 100% 以外的任何縮放下皆採用瀏覽器內插，邊緣可能會變得柔化 |
對大多數疊加工作——標誌、浮水印圖、角落徽章、置中的紋理——缺乏中繼資料保留反而是優點。這代表分享出去的檔案中，不會夾帶相機序號、GPS 座標，也不會留下原始檔名。如果你確實需要保留 EXIF，請另外以本地 EXIF 編輯器處理，於疊加步驟之後再套用。
何時應完全避免使用線上疊圖工具
即使是安全的、瀏覽器端的疊圖工具，也並非適用於所有工作。當以下任一情況適用於相關檔案時，請跳過它，或繞過任何線上工具。首先，如果疊圖必須以精確的像素寬度完成，請在匯出前自行根據疊圖的原始寬度計算縮放比例。100% 以原始大小繪製；50% 將兩個維度都減半；任何目標寬度都可以透過 目標 ÷ 原始 × 100 達成。其次，如果所選比例下的疊圖大於底圖，則超出畫布的部分會依設計被裁切，而非縮放。如果無法接受這種損失，請降低比例或先編輯疊圖來源。
第三，如果您需要自由拖曳、任意的 x/y 座標、旋轉、混合模式、遮罩或重複拼貼，則單一疊圖、確定性錨點的模式並不適合。這些工作屬於具備復原歷史記錄和可見控制點的真正編輯器。第四，如果您在乎元資料的保留，請另外執行元資料步驟；沒有任何線上疊圖工具能同時保持您的像素隱私，並將相機的 EXIF 區塊重新附加到輸出檔案。第五，如果輸入本身的格式是該工具不接受的——SVG、AVIF、動畫 GIF、RAW——請先在本機轉換，而不是將其上傳到可能保留副本的「萬用轉換器」。這些注意事項都不會改變原始問題的答案：是的，只要瀏覽器端圖片疊圖工具實際上是將工作保留在您的分頁中、撤銷其 blob URL，並拒絕超出其宣告限制的輸入，那麼在線上使用它就是安全的。要兌現承諾靠的是驗證，而非信任，這就是為什麼 Image Overlay 會事先公布其限制，並將每個位元組和像素預算視為嚴格、有文件記載的截止點。