要把 GIF 縮得更小，可在保持可見動畫完整的情況下，調整其像素寬度與高度：輸入以整數像素表示的目標寬度，由原始畫布比例自動計算對應的高度，然後匯出按比例縮放後的動畫。寬度是唯一的幾何控制項，因為它能讓長寬比保持明確——一個 800×600 的 GIF 在輸入 400 之後會輸出為 400×300，高度會四捨五入到整數像素。處理後的 GIF 會保留影格順序與每影格的延遲時間，但匯出檔案是重新以調色盤重新編碼而成，而非原始串流的逐位元組複製。這個細節很重要：較小的像素尺寸通常代表每影格的像素數較少，這通常會讓檔案縮小，但調色盤重新編碼與內容複雜度可能會把位元組數往反方向推升。這項作業不會上傳任何內容，所以原始檔會一直留在你的裝置上，直到你選擇下載結果為止。
GIF 縮放工具可以端到端地處理這項工作。開啟頁面，選擇一個不超過 20 MB 的 GIF，確認頁面回報的原始畫布資訊，輸入目的地所需的寬度，然後按下「Resize GIF」。頁面會計算對應的高度，在你的瀏覽器中解碼每一個可見影格，縮放每一張完整的畫布，產生一張新的 GIF，並提供單一的下載連結。
「把 GIF 縮得更小」實際改變了什麼
大多數人會在動畫占用的視覺空間超出目的地允許範圍時，採取縮放這個步驟。一個寬 1200 像素的反應 GIF，對論壇頭像欄位、聊天室側邊欄或說明文件縮圖來說都太寬了。其他時候目標是載入速度：每一影格中的每個像素都必須被下載、解碼並繪製，所以一個 1000×1000 的橫幅，最後只顯示在 250×250 時，等於浪費了四分之三資料的頻寬與 CPU。
把 GIF 縮得更小是像素尺寸的改變，而非檔案格式的改變。檔案格式仍是 GIF。影格數量保持不變。影格之間的相對時間也保持不變。改變的是每張影格邏輯畫布的寬度與高度，依據你輸入的相同比例進行縮放。一個 800×600 的來源，第 1 影格延遲 50 ms、第 2 影格延遲 100 ms，在縮放成 400×300 之後，這些延遲仍然相同——只有畫布變小了。
最後這一點也是縮放有時會與最佳化混淆的原因。縮小像素尺寸通常會減少位元組數，因為需要編碼的像素變少了。但並非總是如此，因為 GIF 是以調色盤為基礎，匯出檔是一次全新的編碼，擁有自己的 256 色調色盤。動畫內容、色彩多樣性，以及編碼器選擇調色盤項目的方式，都會影響最終的大小。
如何使用 GIF 縮放工具把 GIF 縮得更小
這個工具只需要你提供三項東西：一個 GIF、一個目標寬度，以及一次「Resize GIF」點擊動作。其他一切都在瀏覽器中計算或完成。
- 開啟 GIF 縮放工具頁面，選擇一個不超過 20 MB 的動畫 GIF。頁面會讀取 GIF 標頭並顯示偵測到的原始畫布（例如 800 × 600），讓你能確認自己正在處理預期的檔案。
- 以整數像素輸入目標寬度。對應的高度會依據原始畫布比例自動計算。如果來源是 800 × 600，而你輸入 400，輸出就是 400 × 300，高度會四捨五入到整數像素。
- 點選 Resize GIF。頁面會在你的瀏覽器中解碼每一個可見影格，依照其處置指令合成補丁區塊，按比例縮放每一張完整的畫布，把每張輸出影格量化為全新的 GIF 調色盤，然後把結果打包成可下載的 GIF。
- 使用頁面提供的連結下載縮放後的動畫，並在預期的顯示尺寸下於瀏覽器或目標應用程式中開啟。觀察第一輪播放的時間、邊緣品質，以及文字可讀性或透明度是否出現任何變化。
寬度是唯一的幾何輸入。沒有裁切、沒有留白、沒有獨立的高度控制，也沒有要求不同長寬比的方式。如果需要進行這類變更——例如把 4:3 的來源轉成 1:1 的正方形——請在縮放之前於專用編輯器中完成，好讓 GIF 縮放工具能專注於按比例縮放。
為什麼縮放 GIF 不等同於縮放靜態圖片
一張靜態 JPG 或 PNG 就是一張只有一組像素的圖片。GIF 可以只是一張圖片，但它也可能是第一張圖再加上只更新部分邏輯畫布的較小補丁區塊。每塊補丁都可以帶有一條處置指令，說明下一張影格應該保留前一個像素、清除被變動的矩形區域，或恢復成更早的畫布。舉例來說，一個彈跳球的 GIF，可能會在第 1 影格把球畫在一塊透明矩形上，在第 2 影格把球畫低一點，並使用「恢復為背景」的處置指令，依此類推——這代表第 2 影格只有在第 1 影格的像素仍然存在時才有意義。
把每塊原始補丁區塊各自獨立縮放，就像對待一疊分開的圖片，會破壞這個合約。縮放後的「恢復為背景」補丁，可能會在前一影格球所在的位置留下一個透明破洞。「不處置」的補丁，則可能留下原始動畫從未出現的殘影軌跡。GIF 縮放工具避開了這個問題：它先依照處置指令合成每一張影格，再使用標準的 canvas 繪圖 縮放每張完整合成後的畫布，因此輸出代表的是觀看者實際在每個影格邊界應該看到的內容，而不是把底層實作的補丁區塊暴露出來。
這也是為什麼快速的瀏覽器端縮放，看起來會與桌面 GIF 編輯器所做的縮放略有不同：桌面編輯器通常預設就會先合成，而對每塊原始補丁呼叫縮放函式的天真程式碼則不會這麼做。
GIF 縮放工具在匯出前會檢查的限制
瀏覽器會以明確的邊界保護自己，一旦檔案超過任何一項限制，就會在大型輸出畫布被配置之前先予以拒絕。了解這些邊界可以省下一次失敗的上傳，也能解釋當邊緣情況的檔案觸發其中之一時你所看到的錯誤訊息。
| 邊界 | 限制 | 為何重要 |
|---|---|---|
| 所選檔案大小 | 不超過 20 MB | 讓記憶體中的 Blob 與解碼步驟維持在瀏覽器可承受的合理範圍內。 |
| 邏輯畫布（寬度或高度） | 每邊不超過 4,096 像素 | 反映主流瀏覽器在實務上的 canvas 繪圖限制。 |
| 單張影格解碼後的像素數 | 不超過約 3,000,000 像素 | 一個壓縮後的小 GIF 在補丁區塊合成後，仍可能展開成數量龐大的 canvas 像素。 |
| 動畫中的影像影格數 | 不超過 50 | 結合壓縮補丁與輸出工作量上限，避免頁面凍結。 |
如果這些檢查中有任何一項失敗，頁面會顯示錯誤訊息，也不會留下失效的下載連結。原始檔案不會被動到，因此如果需要更小的起點（例如更短的片段、較低解析度的擷取畫面，或影格數較少的 GIF），你可以從不同的來源重新匯出。
你實際下載的內容
下載到的是一張全新編碼的 GIF，而非來源串流的逐位元組縮放版本。即使動畫在肉眼下看起來一模一樣，了解這個差異仍是發布結果前值得弄清楚的事，因為有少數屬性在這一來一往之間並不會保留下來。
| 保留 | 從頭重建 |
|---|---|
| 可見的影格順序 | 調色盤（每張輸出影格最多 256 色） |
| 解碼後的每影格延遲 | 來自原始檔案的中繼資料擴充區塊 |
| 每像素一位元的透明度 | 原始的調色盤表與最佳化策略 |
| 最終畫布的寬度與高度 | 有限循環次數——新的 GIF 會無限循環 |
GIF 的透明度是 1 位元，所以透明像素在匯出後仍然透明——它們無法像 PNG 那樣獲得部分透明值。漸層、抖動處理與細膩的攝影細節，在經過第二次調色盤轉換後也可能出現些微偏移，因為這個新的 256 調色盤是為縮放後的影格挑選的，而非從來源複製。在預期的顯示尺寸下，特別是當來源包含小字、透明、快速動作或平滑色彩過渡時，請開啟下載後的動畫並觀察第一輪播放。Canvas 渲染與色彩管理在不同瀏覽器和顯示器之間可能略有差異，因此最理想的評估方式，是在實際會顯示該動畫的裝置與應用程式上進行。
為什麼較小的 GIF 仍然可能是較大的檔案
縮小尺寸通常會減少每影格的像素數，這幾乎都會帶來幫助。問題在於輸出的 GIF 是以全新調色盤進行編碼，而編碼器會根據縮放後的影格決定調色盤中應包含哪些顏色。一段色彩範圍很廣的短動畫，可能需要比原始檔更密集的調色盤，這會在像素變少的情況下反而推升位元組數。同一段動畫以略大一些的寬度重新編碼時，有可能會落在一個甜蜜點，讓調色盤的運用更有效率，這也是為什麼像素數較少並不保證檔案較小。
匯出完成後，頁面會回報實際的輸出尺寸、影格數與最終大小，因此即便結果違反直覺，也是看得到而不是被藏起來。如果目標是較小的檔案而非較小的像素，下一步通常是減少調色盤，而不是進一步調降寬度。像素尺寸縮放與調色盤縮減是兩條不同的調整途徑，該用哪一條，取決於瓶頸是視覺空間、頻寬，還是兩者皆是。
若要建立可靠的工作流程，請先準備一份原始 GIF 的副本，在 GIF 縮放工具頁面上選取它，確認頁面回報的原始畫布，輸入目的地所需的寬度，然後下載縮放後的版本。於預期的顯示尺寸下在瀏覽器或目標應用程式中測試結果，只有在僅調整尺寸仍不夠時，再針對調色盤或影格速率進行迭代。如果來源包含不支援或毀損的影格資料、具有誤導性的尺寸、過大的解碼工作量，或無效的 GIF 簽章，頁面會顯示錯誤，也不會留下失效的下載連結——因此一次失敗的嘗試，除了花費你一點時間之外，並不會帶來任何損失。
相關閱讀：Gift Split Fiction Moments：Split a GIF into PNG Frames。