最小的透明 GIF 只有 43 位元組。
這就是它的全部。點選任一位元組查看它的作用,然後複製檔案、下載、外連,或用你自己的程式碼來提供它。

每個位元組的作用
GIF 由一連串區塊組成。這個檔案有七個區塊,本頁的每種顏色都對應其中一個。選取一個位元組或區塊即可查看說明。 數值以小端序(little-endian)儲存:低位元組在前,所以 01 00 代表 1。
| 位元組 | 欄位 | 意義 |
|---|---|---|
| 檔頭 告訴解碼器這是 GIF,以及應該依哪個格式版本來解析。 | ||
| 47 49 46 | 簽章 | ASCII 字母「GIF」。每個 GIF 檔案都以它們開頭。 |
| 38 39 61 | 版本 | 「89a」。透明需要 89a;87a 沒有圖形控制擴充。 |
| 邏輯螢幕描述區塊 畫布的尺寸,以及色彩表的設定方式。 | ||
| 01 00 | 畫布寬度 | 1 像素。 |
| 01 00 | 畫布高度 | 1 像素。 |
| 80 | 封裝旗標 | 四項設定擠在一個位元組裡。最高位元表示後面接著全域色彩表;最低三個位元代表它的大小。 |
| 00 | 背景色索引 | 調色盤第 0 項。瀏覽器會忽略它,直接顯示影像後方的內容。 |
| 00 | 像素長寬比 | 0 表示正方形像素,不做校正。 |
| 全域色彩表 調色盤。像素儲存的是指向這個清單的索引,而不是顏色本身。 | ||
| FF FF FF | 調色盤項目 | 紅、綠、藍各佔一個位元組:#ffffff。兩個項目是 GIF 色彩表的最小尺寸。 |
| 00 00 00 | 調色盤項目 | 紅、綠、藍各佔一個位元組:#000000。兩個項目是 GIF 色彩表的最小尺寸。 |
| 圖形控制擴充 GIF89a 新增的選用區塊。這裡用它讓調色盤第 0 項變成透明。 | ||
| 21 | 擴充引導碼 | 0x21(「!」)表示接下來是擴充區塊。 |
| F9 | 圖形控制標籤 | 0xF9 表示這個擴充是圖形控制擴充。 |
| 04 | 區塊大小 | 後面接著 4 位元組的設定。 |
| 01 | 封裝旗標 | 最低位元是透明旗標。它已開啟,因此會使用下方的透明色索引。 |
| 00 00 | 延遲 | 0 個百分之一秒。只對動畫有意義。 |
| 00 | 透明色索引 | 調色盤第 0 項會繪製成完全透明。 |
| 00 | 區塊終止符 | 長度為零的子區塊,用來結束該區塊。 |
| 影像描述區塊 影像在畫布上的位置和大小。 | ||
| 2C | 影像分隔符 | 0x2C(「,」)表示影像開始。 |
| 00 00 | 左側位置 | 影像從距離畫布左緣 0 像素處開始。 |
| 00 00 | 頂端位置 | 影像從距離畫布上緣 0 像素處開始。 |
| 01 00 | 影像寬度 | 1 像素。 |
| 01 00 | 影像高度 | 1 像素。 |
| 00 | 封裝旗標 | 沒有區域色彩表,非交錯式。影像使用全域調色盤。 |
| 影像資料 像素資料,以 LZW 壓縮,並切分成每個最多 255 位元組的子區塊。 | ||
| 02 | LZW 最小碼長 | 2,因此壓縮碼從 3 位元寬開始。 |
| 02 | 子區塊大小 | 後面接著 2 位元組的壓縮資料。 |
| 44 01 | 壓縮像素 | 從最低位元開始封裝的 LZW 碼。下方說明它們如何解碼。 |
| 00 | 區塊終止符 | 長度為零的子區塊,用來結束該區塊。 |
| 結尾 標示檔案結束的一個位元組。 | ||
| 3B | 結尾 | 0x3B(「;」)結束檔案。 |
封裝位元組的內部
這三個位元組各自存放了幾項小設定。第 7 位元在最左邊。
0x800x010x00兩個位元組如何裝下一個像素
最小碼長為 2 時,解碼器讀取 3 位元的碼。碼 4 清空碼表,碼 5 結束影像,碼 0 到 3 對應調色盤項目。位元組 44 01 從最低位元開始讀取:
0x44 010001000x01 00000001
- 001100 = 4清除:從全新的碼表開始
- 000000 = 0像素:調色盤第 0 項
- 101101 = 5影像結束
- 0000000 未使用的填充位元
更大的影像也用同樣的技巧:每個新碼代表比上一個多一個像素的連續像素,所以 1000×1000 的透明 GIF 只需要 1,743 位元組。
還能更小嗎?
可以,只要拿掉解碼器能容忍缺少的部分。我們把每個變體交給三個瀏覽器引擎和 Pillow,並記錄它們畫出的結果。
| 大小 | 變體 | Chromium | Firefox | WebKit | Pillow |
|---|---|---|---|---|---|
| 43 | 本頁的標準檔案。 | 透明 | 透明 | 透明 | 透明 |
| 42 | 沒有結尾位元組。解碼器反正會在資料結束時停止。 | 透明 | 透明 | 透明 | 透明 |
| 37 | 完全沒有調色盤。仍然有效:規格允許解碼器使用自己的調色盤,而且索引 0 本來就是透明的。 | 透明 | 透明 | 透明 | 透明 |
| 36 | 沒有調色盤,也沒有結尾。 | 透明 | 透明 | 透明 | 透明 |
| 35 | 沒有透明區塊:像素以調色盤顏色 0(白色)繪製。 | 白色 | 白色 | 白色 | 白色 |
| 35 | 1987 年的格式。它無法把顏色標示為透明。 | 白色 | 白色 | 白色 | 白色 |
| 34 | 有透明區塊,但沒有壓縮像素。 | 透明 | 透明 | 透明 | 錯誤 |
| 33 | 同上,但拿掉結尾。 | 透明 | 透明 | 透明 | 錯誤 |
| 29 | 沒有調色盤,也沒有透明設定。每個引擎自行選擇顏色。 | 黑色 | 白色 | 透明 | 黑色 |
| 26 | 完全沒有壓縮資料的影像。 | 透明 | 透明 | 透明 | 錯誤 |
| 14 | 只有檔頭、畫布大小和結尾,裡面沒有影像。 | 透明 | 錯誤 | 透明 | 錯誤 |
需要在所有環境都能用時,請用 43 位元組。37 位元組仍是有效的 GIF,而且在我們測試的每個引擎中都顯示為透明。再小就得依賴解碼器的寬容度,29 位元組的檔案就呈現了各引擎之間的分歧。
於 2026年9月23日 以 Chromium 153.0.8010.12, Firefox 155.0, WebKit 26.6, Pillow 12.2.0 測試。
同一個像素,換成其他格式
我們為每種格式做出能做到的最小透明 1×1 檔案,並交給同樣的四個引擎。展開一列即可檢視它的位元組,顏色與負責相同工作的 GIF 區塊一致。
| 大小 | 檔案 | data URI | Chromium | Firefox | WebKit | Pillow |
|---|---|---|---|---|---|---|
| 28 | WebP 同上,但拿掉兩個填補位元組。WebKit 會拒絕小於 30 位元組的 WebP 檔案。52 49 46 46 14 00 00 00 57 45 42 50 56 50 38 4c 08 00 00 00 2f 00 00 00 10 88 88 08
| 63 | 透明 | 透明 | 錯誤 | 透明 |
| 30 | WebP 無損 VP8L。每個前綴碼只含一個符號,所以像素不佔任何位元,檔案大小在 16384×16384 以內都不變。52 49 46 46 16 00 00 00 57 45 42 50 56 50 38 4c 0a 00 00 00 2f 00 00 00 10 88 88 08 00 00
| 63 | 透明 | 透明 | 透明 | 透明 |
| 43 | GIF 本頁頂端的 43 位元組 GIF。47 49 46 38 39 61 01 00 01 00 80 00 00 ff ff ff 00 00 00 21 f9 04 01 00 00 00 00 2c 00 00 00 00 01 00 01 00 00 02 02 44 01 00 3b
| 82 | 透明 | 透明 | 透明 | 透明 |
| 58 | BMP 傳統的 40 位元組檔頭沒有 alpha 遮罩,所以第四個位元組會被忽略,像素在所有引擎中都是黑色。42 4d 3a 00 00 00 00 00 00 00 36 00 00 00 28 00 00 00 01 00 00 00 01 00 00 00 01 00 20 00 00 00 00 00 04 00 00 00 13 0b 00 00 13 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 102 | 黑色 | 黑色 | 黑色 | 黑色 |
| 62 | SVG 只有寬度和高度的空 | 85 | 透明 | 透明 | 透明 | 錯誤 |
| 67 | PNG 含 alpha 的全彩。唯一一條全零掃描線是手工壓縮的,比 zlib 最高壓縮設定還短 1 位元組。89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 01 00 00 00 01 08 06 00 00 00 1f 15 c4 89 00 00 00 0a 49 44 41 54 78 01 63 00 01 00 00 05 00 01 36 d0 88 dd 00 00 00 00 49 45 4e 44 ae 42 60 82
| 114 | 透明 | 透明 | 透明 | 透明 |
| 70 | ICO 包含一張 32 位元點陣圖及其 1 位元 AND 遮罩的網站圖示。00 00 01 00 01 00 01 01 00 00 01 00 20 00 30 00 00 00 16 00 00 00 28 00 00 00 01 00 00 00 02 00 00 00 01 00 20 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00
| 121 | 透明 | 透明 | 透明 | 透明 |
| 74 | BMP 含 alpha 遮罩的 56 位元組檔頭。WebKit 無法載入。42 4d 4a 00 00 00 00 00 00 00 46 00 00 00 38 00 00 00 01 00 00 00 01 00 00 00 01 00 20 00 03 00 00 00 04 00 00 00 13 0b 00 00 13 0b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 ff 00 00 00 00 00 00 ff 00 00 00 00
| 122 | 透明 | 透明 | 錯誤 | 透明 |
| 89 | ICO 包含那張 67 位元組 PNG 的網站圖示。00 00 01 00 01 00 01 01 00 00 01 00 20 00 43 00 00 00 16 00 00 00 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 01 00 00 00 01 08 06 00 00 00 1f 15 c4 89 00 00 00 0a 49 44 41 54 78 01 63 00 01 00 00 05 00 01 36 d0 88 dd 00 00 00 00 49 45 4e 44 ae 42 60 82
| 145 | 透明 | 透明 | 透明 | 透明 |
| 126 | BMP V4 檔頭。WebKit 會忽略其 alpha 遮罩並畫成黑色。42 4d 7e 00 00 00 00 00 00 00 7a 00 00 00 6c 00 00 00 01 00 00 00 01 00 00 00 01 00 20 00 03 00 00 00 04 00 00 00 13 0b 00 00 13 0b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 ff 00 00 00 00 00 00 ff 42 47 52 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 190 | 透明 | 透明 | 黑色 | 透明 |
| 142 | BMP V5 檔頭,在 WebKit 中結果相同。42 4d 8e 00 00 00 00 00 00 00 8a 00 00 00 7c 00 00 00 01 00 00 00 01 00 00 00 01 00 20 00 03 00 00 00 04 00 00 00 13 0b 00 00 13 0b 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 ff 00 00 00 00 00 00 ff 42 47 52 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 214 | 透明 | 透明 | 黑色 | 透明 |
| 437 | AVIF 同上,但使用 4:0:0 色度取樣,拿掉了顏色平面。00 00 00 1c 66 74 79 70 61 76 69 66 00 00 00 00 61 76 69 66 6d 69 66 31 6d 69 61 66 00 00 01 6a 6d 65 74 61 00 00 00 00 00 00 00 21 68 64 6c 72 00 00 00 00 00 00 00 00 70 69 63 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 70 69 74 6d 00 00 00 00 00 01 00 00 00 2c 69 6c 6f 63 00 00 00 00 44 00 00 02 00 01 00 00 00 01 00 00 01 a0 00 00 00 15 00 02 00 00 00 01 00 00 01 8e 00 00 00 12 00 00 00 42 69 69 6e 66 00 00 00 00 00 02 00 00 00 1a 69 6e 66 65 02 00 00 00 00 01 00 00 61 76 30 31 43 6f 6c 6f 72 00 00 00 00 1a 69 6e 66 65 02 00 00 00 00 02 00 00 61 76 30 31 41 6c 70 68 61 00 00 00 00 1a 69 72 65 66 00 00 00 00 00 00 00 0e 61 75 78 6c 00 02 00 01 00 01 00 00 00 a7 69 70 72 70 00 00 00 81 69 70 63 6f 00 00 00 14 69 73 70 65 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 0e 70 69 78 69 00 00 00 00 01 08 00 00 00 0c 61 76 31 43 81 00 1c 00 00 00 00 13 63 6f 6c 72 6e 63 6c 78 00 01 00 0d 00 06 80 00 00 00 38 61 75 78 43 00 00 00 00 75 72 6e 3a 6d 70 65 67 3a 6d 70 65 67 42 3a 63 69 63 70 3a 73 79 73 74 65 6d 73 3a 61 75 78 69 6c 69 61 72 79 3a 61 6c 70 68 61 00 00 00 00 1e 69 70 6d 61 00 00 00 00 00 00 00 02 00 01 04 01 02 83 04 00 02 04 01 02 83 05 00 00 00 2f 6d 64 61 74 12 00 0a 04 18 00 06 15 32 08 10 00 00 18 e1 42 72 10 12 00 0a 07 18 00 06 18 08 68 35 32 08 10 00 00 18 e1 42 72 10
| 607 | 透明 | 透明 | 透明 | 透明 |
| 471 | AVIF libavif 以 quality 100 輸出的結果:一張負責顏色、一張負責 alpha 的 AV1 影像,裝在 ISO BMFF 的 box 中。00 00 00 20 66 74 79 70 61 76 69 66 00 00 00 00 61 76 69 66 6d 69 66 31 6d 69 61 66 4d 41 31 42 00 00 01 86 6d 65 74 61 00 00 00 00 00 00 00 21 68 64 6c 72 00 00 00 00 00 00 00 00 70 69 63 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 70 69 74 6d 00 00 00 00 00 01 00 00 00 2c 69 6c 6f 63 00 00 00 00 44 00 00 02 00 01 00 00 00 01 00 00 01 c0 00 00 00 17 00 02 00 00 00 01 00 00 01 ae 00 00 00 12 00 00 00 42 69 69 6e 66 00 00 00 00 00 02 00 00 00 1a 69 6e 66 65 02 00 00 00 00 01 00 00 61 76 30 31 43 6f 6c 6f 72 00 00 00 00 1a 69 6e 66 65 02 00 00 00 00 02 00 00 61 76 30 31 41 6c 70 68 61 00 00 00 00 1a 69 72 65 66 00 00 00 00 00 00 00 0e 61 75 78 6c 00 02 00 01 00 01 00 00 00 c3 69 70 72 70 00 00 00 9d 69 70 63 6f 00 00 00 14 69 73 70 65 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 10 70 69 78 69 00 00 00 00 03 08 08 08 00 00 00 0c 61 76 31 43 81 00 0c 00 00 00 00 13 63 6f 6c 72 6e 63 6c 78 00 01 00 0d 00 06 80 00 00 00 0e 70 69 78 69 00 00 00 00 01 08 00 00 00 0c 61 76 31 43 81 00 1c 00 00 00 00 38 61 75 78 43 00 00 00 00 75 72 6e 3a 6d 70 65 67 3a 6d 70 65 67 42 3a 63 69 63 70 3a 73 79 73 74 65 6d 73 3a 61 75 78 69 6c 69 61 72 79 3a 61 6c 70 68 61 00 00 00 00 1e 69 70 6d 61 00 00 00 00 00 00 00 02 00 01 04 01 02 83 04 00 02 04 01 05 86 07 00 00 00 31 6d 64 61 74 12 00 0a 04 18 00 06 15 32 08 10 00 00 18 e1 42 72 10 12 00 0a 08 18 00 06 08 08 68 34 20 32 09 10 00 00 00 07 c8 24 c6 62
| 651 | 透明 | 透明 | 透明 | 透明 |
- 簽章
- 尺寸
- 調色盤
- 透明
- 容器
- 像素
- 結尾
- 中繼資料
- 填補
在四個引擎中都顯示為透明的最小檔案是 WebP,大小 30 位元組,比 GIF 少 13 位元組。
data URI 的長度(字元數):SVG 為 URL 編碼的文字,其餘為 base64。 於 2026年9月24日 以 Chromium 153.0.8010.12, Firefox 155.0, WebKit 26.6, Pillow 12.2.0 測試。AVIF 由 libavif 1.4.1 產生。
產生任意尺寸
透明或單色,從 1×1 到 65535×65535。在你的瀏覽器中產生,不會上傳任何東西。
直接外連
可以從任何網站、電子郵件或 App 直接連結這些檔案。它們由 Cloudflare 的邊緣節點提供,快取時間長,並對所有來源開放 CORS。
- 43 位元組檔案
https://emptygif.com/1x1.gif - 任意尺寸,透明
https://emptygif.com/px/300x250.gif - 任意尺寸,單色
https://emptygif.com/px/300x250/ff5a1f.gif - PNG、WebP 或 SVG 也一樣
https://emptygif.com/px/300x250.webp - JSON API:檔案大小、base64 與 data URI
https://emptygif.com/api/gif?w=300&h=250 - 所有程式碼片段的 JSON
https://emptygif.com/snippets.json - 給 AI 代理的摘要
https://emptygif.com/llms.txt
回應標頭
HTTP/2 200
content-type: image/gif
content-length: 43
cache-control: public, max-age=31536000, immutable
access-control-allow-origin: *
cross-origin-resource-policy: cross-origin
timing-allow-origin: *範例
<img src="https://emptygif.com/1x1.gif" width="1" height="1" alt="">
產生的尺寸每邊最多 4096 像素。如果流量很大,請下載檔案自行託管。
在你的技術堆疊中提供它
191 個可直接執行的程式碼片段。挑一個適合你的:每個都會在你指定的路徑回傳 image/gif 回應。如果你在上方改了尺寸或顏色,程式碼片段會使用那個 GIF。
JavaScript & TypeScript
- Next.js (App Router)
- Hono
- Bun.serve
- Elysia
- Deno.serve
- SvelteKit
- Nuxt (Nitro server route)
- Astro
- React Router (framework mode, ex-Remix)
- TanStack Start
- SolidStart
- Hono on Bun
- Hono on Deno
- srvx (universal fetch server)
- Qwik City
- RedwoodSDK
- Angular SSR (Express server.ts)
- Fresh
- Oak
- Encore.ts
- NestJS
- Fastify
- Express
- Node.js standard library (node:http)
- Koa
- hapi
- AdonisJS
Edge & serverless
- Cloudflare Workers
- Cloudflare Workers (Rust, workers-rs)
- Cloudflare Pages Functions
- Spin (Rust, WASI HTTP component)
- Deno Deploy (deno serve)
- Vercel Functions
- Netlify Functions
- Netlify Edge Functions
- AWS Lambda (Node.js)
- AWS Lambda (Python)
- AWS Lambda (Go)
- AWS Lambda (Rust, lambda_http)
- AWS Lambda@Edge (CloudFront)
- Google Cloud Run functions (Node.js)
- Google Cloud Run functions (Python)
- Firebase Cloud Functions + Hosting
- Azure Functions (Node.js v4 model)
- Fastly Compute (JavaScript)
Python
Go
JVM
PHP
Elixir, Erlang & Gleam
Functional languages
C, C++ & systems languages
Swift, Dart & other languages
Web servers & proxies
Command line & one-liners
Express JavaScript
import express from 'express';
const GIF = Buffer.from('R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==', 'base64');
const app = express();
app.get('/pixel.gif', (req, res) => {
res.set('Cache-Control', 'no-store');
res.type('gif').send(GIF);
});
app.listen(8080);
我們執行了這段程式碼,並比對了它回傳的位元組。 開啟頁面
用途
- 追蹤像素與信標:伺服器記錄請求,並以最小的有效圖片回應。
- 延遲載入圖片的預留位置,讓
img標籤在真正的圖片來源到位前就是有效的。 - HTML 電子郵件中的固定尺寸間隔圖,因為郵件裡的 CSS 支援參差不齊。
- 需要真實圖片、又不想附帶圖檔的測試與 mock。
追蹤像素沒有看起來那麼可靠
開啟「郵件隱私保護」後,Apple Mail 會透過代理伺服器預先載入遠端圖片,所以一次「開啟」可能根本不是真人。Gmail 也會透過自己的代理伺服器擷取並快取圖片。許多用戶端預設會封鎖遠端圖片。做網頁分析時,navigator.sendBeacon() 或 204 No Content 回應通常比圖片更合適。
常見問題
- 明明有一個像素,為什麼叫「空」?
- GIF 至少要有一個像素。這個是 1×1,唯一的顏色被標示為透明,所以什麼都不會顯示。
- 這個 43 位元組的檔案有效嗎?
- 有效。它完全遵循 GIF89a 規格,上表中的每個引擎都把它繪製為透明。
- 為什麼用 GIF,而不是 PNG 或 WebP?
- 它比最小的透明 PNG 還小,而且過去 35 年來的所有瀏覽器、郵件用戶端和圖片函式庫都能讀取它。
- 該用 data URI 還是檔案?
- data URI 能省下一次請求,適合預留位置和 CSS。如果請求本身才是重點(例如追蹤像素),就需要檔案或端點。
- 該送出哪個 Content-Type?
image/gif。如果每個請求都必須到達你的伺服器,再加上Cache-Control: no-store。