GIF 調整尺寸工具會在保留原始長寬比的前提下，調整動態 GIF 的像素尺寸；而像 GIF Resizer 這種以瀏覽器為基礎的工具，會在本地端完成這項工作，不會將檔案上傳到伺服器。調整尺寸的意義在於重寫每一個可見幀所繪製的畫布，然後重新編碼動畫，讓循環、幀順序以及每幀延遲在新尺寸下仍能正確播放。由於 GIF 每幀使用最多 256 色的固定調色盤，因此輸出會是一個重新編碼的檔案，而不是原始資料流的逐位元組縮放。寬度是唯一的幾何控制項，因為這樣可以避免歧義：輸入以整數像素表示的目標寬度，高度就會依據來源畫布比例自動計算並四捨五入到整數像素。完成後會下載成單一的新 GIF 檔，讓你可以在任何可以播放 GIF 的地方開啟。這件事很重要，因為許多 GIF 是以第一張影像加上增量修補的方式儲存，所以如果只縮放原始修補區塊，可能會留下破洞、殘影或遺失的背景；正確的調整尺寸工具會先合成可見的畫布，再進行縮放。
調整尺寸在像素層級實際改變了什麼
調整 GIF 尺寸是對每個可見幀所繪製的邏輯畫布進行的像素尺寸變更。來源長寬比（寬除以高）保持不變，因此當你縮短其中一邊時，另一邊也會以相同的比例縮小。一個 800 乘 600 的來源縮放為寬度 400 時，會輸出 400 乘 300；同樣的來源縮放為寬度 200 時，則會輸出 200 乘 150。這個比例規則正是動畫在調整尺寸後看起來仍與原本相同，而不是被拉長或壓縮的原因。
調整尺寸與檔案大小無關。把每個線性尺寸各縮減一半，大約會減少四分之三的畫布像素，但編碼後的位元組大小仍取決於這些像素的內容、每幀所需的不同顏色數，以及 LZW 壓縮對重複圖樣的利用程度。這就是為什麼 GIF Resizer 會在編碼後回報實際輸出的尺寸、幀數以及最終位元組大小，而不是事先承諾一個百分比降幅。
為什麼幀在縮放前必須先合成
許多 GIF 並非以一疊完整圖片的方式儲存。第一幀通常是一張完整的影像，但後續的幀經常是較小的矩形修補區塊，只更新畫布的局部範圍。每個修補區塊也可能帶有釋出指令，告訴解碼器在下一幀播放前要對受影響的矩形做什麼：保留先前的像素、清除變更的矩形，或是還原到先前的畫布。如果調整尺寸工具把每個修補區塊都當作完整圖片來處理並各自獨立縮放，那麼遺失的背景永遠不會被繪製出來，殘影會被留在原處，而本應由下一幀填滿的地方則會出現透明破洞。
GIF Resizer 透過讀取幀描述元與釋出設定，先將每幀合成到完整的邏輯畫布上，然後才對完整的可見結果進行縮放，從而避免上述問題。因此輸出代表的是觀看者在每個幀邊界應該看到的內容，而不是原始的實作修補區塊。相同的邏輯也說明了為什麼獨立的 GIF Splitter 會在你需要時提供原始修補區塊，以及為什麼縮放必須發生在已合成的畫布上，才能在視覺上忠實還原原始動畫。
三個步驟調整動態 GIF 的尺寸
- 選擇一個大小不超過 20 MB 的動態 GIF，並確認頁面所回報的偵測到的來源畫布。
- 輸入以整數像素表示的目標寬度；對應的高度會依據來源畫布比例自動計算。
- 選擇 Resize GIF，然後下載新的動畫並在其預定顯示尺寸下檢視。
以具體的數字驗證，一個 800 乘 600 的來源在目標寬度 400 下會輸出 400 乘 300：400 ÷ 800 = 0.5，而 600 × 0.5 = 300。頁面會將計算出的高度四捨五入到整數像素，讓輸出維持在 GIF 規格範圍內。使用整數像素的寬度能讓調整尺寸不產生歧義，並讓檔案能安全地放進任何預期整齊像素邊界的版面配置中。
瀏覽器在解碼前強制執行的硬性限制
頁面會拒絕超出其宣告限制的輸入，而不是配置一個巨大的畫布讓分頁當機。這個限制之所以存在，是因為一個小的壓縮 GIF 在每幀解碼後可能會展開成數量龐大的畫布像素。
| 限制 | 數值 | 為何重要 |
|---|---|---|
| 選擇的檔案大小 | 最多 20 MB | 較大的上傳會在任何解碼工作開始前遭到拒絕。 |
| 邏輯畫布每邊 | 最多 4,096 px | 符合常見的 GIF 解碼器，並讓記憶體用量可預測。 |
| 單幀像素數 | 最多 3,000,000 | 防止狹長畫布在不知不覺間超出記憶體。 |
| 影像幀數 | 最多 50 | 為動畫的解碼與編碼總工作量設下上限。 |
| 輸出寬度控制 | 僅限寬度 | 高度由來源比例推導，以維持明確的長寬比。 |
如果你的來源檔案未通過這些檢查中的任何一項，頁面會顯示錯誤訊息，且不會留下任何過期的下載檔案。即使是一個極小的檔案，只要它帶有不尋常的長幀描述元或會展開成大量解碼過程的隱藏延遲表，這層限制檢查仍是讓編碼工作量保持可預測的原因。關於在調整尺寸後縮減檔案大小的工作流程，請參閱在不損失品質的前提下縮減 GIF 大小指南。
新的 GIF 保留了哪些內容，又捨棄了哪些內容
輸出是一個重新編碼的 GIF，而不是原始資料流的逐位元組縮放。當你比較結果與來源時，什麼會在調整尺寸後存活、什麼會被捨棄，兩者之間的關係很重要。
| 保留 | 取代或移除 |
|---|---|
| 依原始順序的可見幀 | 原始調色盤表 |
| 解碼後的每幀延遲 | 詮釋資料擴充區段與註解 |
| 單一位元透明度 | 來源的最佳化策略 |
| 連續循環 | 有限的循環次數（預設為無限） |
由於 GIF 使用基於調色盤的色彩，瀏覽器會為每個完整的輸出幀建立一個最多 256 色的新調色盤。漸層、攝影層次的細節以及抖色效果在經過這第二次的調色盤轉換後，可能會看起來不一樣，因此在上傳發布前請檢查下載的動畫。縮小尺寸通常會減少像素數，但並不保證檔案會變小。如果想要一個更直接、聚焦於調色盤選擇而非幾何尺寸的工具，專屬的 GIF Optimizer 會為本機的 GIF 套用更小的調色盤，並回報實際的輸出大小，而不是先承諾一個結果。
頁面使用標準的瀏覽器畫布繪製，以及本機的 object URL 來處理新的 Blob，因此這個工作流程適用於任何已經能播放 GIF 的現代桌面或行動瀏覽器。不需要帳號，來源檔案與解碼後的像素都會留在裝置上，目前分頁關閉後不會保留任何資料。
什麼時候「僅依寬度」是合適的工具
當目的端需要特定的寬度，且來源的長寬比已經正確時，請使用 GIF Resizer：例如網站欄位、文件縮圖、聊天頭像位置，或任何希望高度自動依寬度決定的版面配置。當你希望調整尺寸的過程在裝置上完成，來源檔案與解碼後的像素都不會離開分頁時，它也是正確的選擇。
當你真正想要變更長寬比、裁切為矩形、填補至更大的方塊、旋轉動畫、加上字幕，或反轉循環時，它就不是合適的工具。請先在獨立步驟中完成這些編輯：以 Image Cropper 處理靜態畫面、以 GIF Maker 處理新的幀清單，或使用字幕工具加上文字圖層。接著再透過 GIF Resizer 調整完成的動畫尺寸，讓最終的像素尺寸符合目的端。如果要在調整尺寸前，將靜態或受支援的動態 WebP 轉換成可下載的 GIF，獨立的 WebP to GIF 步驟能讓工作流程保持明確。
如果來源帶有不受支援或損毀的幀資料、誤導性的尺寸、過大的解碼工作量，或無效的 GIF 簽章，頁面會回報錯誤，且不會留下任何局部的下載檔案。這個調整尺寸功能在目前瀏覽器已經能解碼的一般網頁 GIF 上表現最佳，而這也涵蓋了幾乎所有從螢幕錄影工具、聊天擷取畫面或設計工具匯出的 GIF 情境。
如果你正在權衡各種選項，如何將 GIF 分割成影像對此有詳細說明。