多數人覺得，把文字燒進圖片裡只是一個排版選擇，反正字都在畫面上，使用者看得到，效果好像沒差多少。這個選擇其實同時關掉了好幾道門：搜尋引擎讀不到、AI 答案引擎抓不到、螢幕報讀軟體念不出來、瀏覽器選不到字也翻不了譯、螢幕一放大字型就先糊掉。
這件事在網頁設計圈吵了十幾年，長期被簡化成「對 SEO 好不好」的單一問題，但真正的代價分散在完全不同的系統裡，一部分卡在演算法怎麼解析內容，一部分卡在誰在讀這個頁面。圖片文字（image of text），指的是原本可以用真實文字呈現的內容，被做成點陣圖或向量圖裡的視覺元素，標語、按鈕上的字、資訊圖表裡的數字，都算在內。判斷該不該這樣做，不能只看畫面好不好看，得先弄清楚這段文字承載了什麼工作。
搜尋引擎是最直接、也最容易驗證的一道破口。
搜尋引擎讀不到燒進圖片裡的文字
把文字燒進圖片，等於把這段資訊從搜尋引擎能理解的內容裡整段拿掉。這不是比喻，而是機制問題。搜尋引擎索引的對象是網頁裡的文字節點（text node），也就是 HTML 裡實際存在的字元；圖片本身，不管是 CSS 背景圖還是單純的 JPG、PNG 檔案，對演算法來說都只是一張圖。就算圖片裡的像素排列成一模一樣的文字，人眼看起來完全一樣，對搜尋引擎而言那仍然是一張圖，不是一段文字，沒有語意標記，不會被辨識成標題或清單，也沒辦法被拆解成關鍵字去比對使用者的搜尋意圖。
Google 官方的開發者風格指南講得很直接，多數情況下要避免把說明性文字嵌進示意圖或截圖裡，因為圖片裡的文字會傷害無障礙與可搜尋性，若圖表之後要做多語言在地化，成本也會跟著墊高；真的必須嵌入文字，也要另外用一段文字說明把同樣的資訊再講一次，讓看不到圖片的人拿得到。同一套規範在 Google 的無障礙文件裡又被重申一次，螢幕截圖、程式碼樣本、終端機輸出這幾種常見的圖片文字，一律建議改用真正的文字呈現。
Google 的圖片搜尋最佳做法頁面也直接示範了兩種寫法的差別。比較好的做法，是把說明文字寫進圖片的替代文字屬性，讓 Google 讀得到；比較差的做法，是把文字直接畫在背景圖上、透過 CSS 疊在畫面上。Google 在這裡講得毫不含糊，這種做法建立不了索引，因為 Google 不會為 CSS 背景圖片建立索引。換句話說，畫面上看起來一模一樣的兩段文字，一段進得了搜尋結果，另一段連被讀到的機會都沒有。
AI 答案引擎同樣讀不到圖片裡的文字
把視角從傳統搜尋引擎拉到 AI 答案引擎，問題並沒有消失，反而換了一種更容易被誤會的方式出現。多數人以為，現在的 AI 模型本身有影像辨識能力，在瀏覽網頁回答問題時，應該也讀得懂圖片裡燒進去的文字。這個假設在實際測試裡並不成立。國際 AI 搜尋監測平台 Otterly.AI 針對 ChatGPT、Google AI Mode、Gemini、Perplexity、Microsoft Copilot 這五個平台做過一組實測，把一個虛構的事實數字，用文字疊圖的方式直接燒進一張照片的像素裡，不放進檔名、不放進替代文字、不放進圖說，也不放進周邊的內文段落。同一份實測總共執行 120 次，結果這個燒進圖片裡的文字版本，五個平台全部零命中，行為跟完全沒有任何線索的對照組一樣，不是給錯答案，就是直接編造一個答案出來。研究團隊的結論是，AI 搜尋平台在非深度思考模式下，並不會用光學文字辨識（OCR）去抽取圖片裡的事實資訊，即使那段文字清晰、對比度高、人眼一看就懂。
同一份實測裡，唯一有部分成功的組合，是把同樣的資訊同時寫進圖片檔名與替代文字，這仍然是文字管道，不是燒進像素裡。就算如此，五個平台裡也只有 ChatGPT 答對，機率落在 75%，其餘四個平台仍然答錯或編造答案。連文字管道這條相對友善的路徑，都只有一個平台能穩定辨識出來，完全仰賴像素裡的文字，等於直接放棄被 AI 答案引擎讀到的機會。Otterly.AI 給的具體建議很實際。真正重要的資訊要寫進內文的段落或小標裡，不要只靠圖片檔名、替代文字、圖說，更不要只靠燒進圖片裡的文字去承載。
圖片文字對螢幕報讀軟體形同虛設
從演算法轉到活生生的使用者，問題不會比較輕。螢幕報讀軟體（screen reader）念的是頁面裡可以被程式判讀的文字，圖片裡的像素排成什麼字，報讀軟體完全沒有能力自己解讀出來，只能念出這張圖有沒有填替代文字（alt text）。沒填，這段內容對使用報讀軟體的人來說就等於不存在，不是讀起來比較差，是整段資訊直接消失。
「有替代文字就沒事」是個安慰劑心態，侷限也值得說清楚。替代文字是對原始文字內容的濃縮轉譯，原本的排版、強調的語氣、字級大小這些真文字才帶得動的資訊，換成一句簡短的描述之後，多半會流失。W3C 網頁內容無障礙指引（WCAG）對圖片文字的定義，是為了達成特定視覺效果而以非文字形式呈現的文字，並在第 1.4.5 條成功標準裡規定，只要當下使用的技術做得到相同的視覺呈現，就該用真文字傳達資訊，不要用圖片文字，但商標與藝術排版這類情況是例外。
不過，連有沒有填替代文字這一關，全球網站都還沒做好。無障礙研究機構 WebAIM 每年針對全球流量前 100 萬個首頁做自動化掃描，2026 年最新一輪發現，53.1% 的首頁至少有一張圖片缺少替代文字；換算成圖片數量，全部樣本裡 16.2% 的圖片，平均每頁 10.8 張，沒有替代文字。報告同時指出，若把「有填但寫得敷衍」也算進去，像是替代文字直接填檔名、或填「image」「graphic」這種空話，問題涵蓋的圖片比例超過四分之一。文字燒進圖片、又沒補替代文字的做法，等於把這個已經很普遍的破口再加重一層。
圖片文字做不到選字複製與翻譯
除了讀不讀得到，還有一層是使用者能不能對這段文字做動作。真文字可以被滑鼠反白選取、複製貼上、用瀏覽器內建的整頁翻譯功能轉換語言、用尋找功能在頁面裡搜尋關鍵字；圖片裡的文字，這四件事全部做不到。原因同樣出在資料型態上，瀏覽器能操作的最小單位是文字節點，圖片對瀏覽器來說是一整塊不可分割的像素矩陣，沒有文字節點可以選、可以搜尋、可以送進翻譯引擎。
這對接觸海外客戶、或者瀏覽習慣仰賴整頁翻譯的使用者尤其實際。Google Chrome 官方說明頁面解釋了整頁翻譯與選取文字翻譯這兩個功能怎麼運作，整頁翻譯是瀏覽器偵測頁面語言後自動跳出翻譯列；選取文字翻譯，則要求使用者先反白該段文字才能點選翻譯，兩種模式都建立在「這段內容是可被反白的文字節點」這個前提上。圖片裡的文字沒辦法被滑鼠反白，自然就進不了這套翻譯流程，這跟手機版 Google 翻譯另外提供的拍照辨識翻譯是完全不同的功能，那是相機光學辨識，不是網頁本身內建的整頁翻譯，兩者不能混為一談。對一個想把整個頁面轉成自己語言的跨境瀏覽者來說，圖片裡的文字就是一塊語言孤島，翻譯功能直接跳過它，好像它根本不存在。
螢幕縮放時圖片文字先失焦模糊
跳出讀取與操作這兩層問題，圖片文字還有一個更物理層面的弱點，換了顯示尺寸，它就可能先垮掉。同一段文字，換了螢幕或換了顯示方式，結果可能完全不一樣。用真文字呈現時，字型是瀏覽器即時運算描繪出來的，不管螢幕多大、使用者有沒有放大頁面、是不是視網膜等級的高解析度螢幕，文字邊緣永遠銳利。圖片文字則是先被烘成固定像素的點陣圖，一旦顯示尺寸超過原始解析度，不管是手機上放大檢視、使用者按下放大鍵、還是高密度螢幕需要更多像素才夠銳利，這些固定的像素就會被硬拉伸，邊緣糊成鋸齒或色塊，而且沒有回頭路，不像真文字可以隨時重新描繪。這正是響應式網頁設計（RWD）年代，圖片文字最容易現形的破綻，同一個版面在桌機看沒問題，換到手機放大兩三下，圖片裡那行字就先糊掉。
Mozilla 官方開發者文件（MDN）對點陣圖與向量圖的技術差異講得很清楚，點陣圖記錄的是每個像素該放在哪、該是什麼顏色，放大之後，每個像素會被放大填進畫面上多個像素的位置，圖像因此開始出現方塊感；向量圖則不會在放大或縮放到很大的尺寸時失真。文字用 HTML 與 CSS 呈現時，瀏覽器把它當成向量字型即時運算，行為上等同向量圖；文字一旦燒進 JPG 或 PNG，就繼承了點陣圖放大必糊的物理限制，再也回不去。
W3C 網頁內容無障礙指引對圖片文字這條規範背後的用意，也呼應這一點，是要讓需要調整文字呈現方式的使用者可以自行客製化。官方文件列出的受益對象包括：視力不佳、難以用原始字型與字級或顏色閱讀文字的人，可以自行調整這幾項視覺參數；有視覺追蹤困難、難以用原始行距或對齊方式閱讀的人，可以自行重新排版。這些客製化能力，只有真文字才有，圖片裡的文字沒辦法讓使用者調字級、換配色、調行距，畫面被烘進圖片的那一刻，這些彈性就全部關掉了。
商標、標語、藝術排版與字型限制，這幾種情況我認可
講完前面幾種代價，我要正式表態，我認為有四種情況，把文字做成圖片是可以接受的，不是各打五十大板的和稀泥，品牌識別的商標字、純視覺裝飾的主視覺標語、以藝術排版為本體的海報式設計，以及字型未取得網頁授權或跨平台顯示不穩定時的技術妥協，都算數。
品牌識別這一條最沒有爭議，商標與品牌名稱的視覺呈現本身就是識別的一部分，換成任何網頁字型都會失去辨識性，這是全球無障礙規範直接認列的例外。純視覺標語則是另一種情況，用來營造氣氛、不承載任何需要被查找或朗讀的具體資訊的裝飾性短句，拿掉這句話，不影響任何人理解頁面在提供什麼服務或資訊。藝術排版類的設計，文字本身的視覺呈現，包括字體選字、扭曲、疊加效果，就是設計要傳達的美感本身，換成任何網頁安全字型，都會讓作品失去意義。至於字型限制這一種比較技術性，需要精準字型渲染，但該字型沒有取得網頁授權嵌入，或某些特殊符號在不同瀏覽器與裝置上顯示不穩定，這時用圖片鎖住視覺效果，是合理的技術妥協。舉兩個去識別化的情境，一場音樂節的主視覺海報，或一家手工烘焙小店在網站首頁放的一句手寫體標語，都屬於這一類。
W3C 網頁內容無障礙指引第 1.4.5 條的正式例外條款，明文列出兩種情況：「可客製化」，這段圖片文字可以依使用者需求重新調整視覺呈現；以及「本質必要」，某種特定的文字呈現方式，對這則資訊要傳達的內容來說是不可或缺的。條文附註特別點名，屬於商標或品牌名稱一部分的文字，直接歸類為本質必要。條文說明段落進一步舉例什麼叫本質必要：字體樣本、商標、品牌識別，以及使用一種沒有廣泛部署、或作者沒有重製授權的字型，正好對應前面提到的字型限制那一種情況。官方給的範例也包含兩種，一是含文字的商標圖片，商標圖本身不可調整文字，但要另外附文字說明；二是介紹某個字體家族時，用圖片示範才能不失真呈現那個字體真正的樣子。
好不好看不是判準，資訊要不要被找到才是
圖片文字有五種讀不到、用不到的代價，也有四種站得住腳的例外。收束到最後，真正該問的問題只有一個。這段文字承不承載需要被搜尋、被朗讀、或被選取與翻譯的資訊？
從搜尋角度看，有沒有人可能搜尋這段文字裡的關鍵字，或者它是不是頁面主題判讀的重要依據。從朗讀角度看，拿掉這段文字，螢幕報讀軟體的使用者會不會因此漏掉一則對他有用的資訊，這裡指的是漏掉資訊，不是漏掉畫面好不好看這件事。至於選取與翻譯，跨語言或需要複製轉貼的使用者，會不會因為讀不到這段內容，選字或翻譯的動作就進行不下去。三個角度只要有一個答案是「會」，這段文字就該用真文字呈現，不管視覺效果好不好看都一樣；三個角度全部是「不會」，純粹是品牌識別、氣氛裝飾、藝術效果本身，才輪到上一節那四種例外登場。
而且就算落在例外範圍裡，前提也沒有變。同樣的資訊，還是要在替代文字屬性或緊鄰的真文字裡再說一次，讓需要它的人，包括搜尋引擎、AI 答案引擎、報讀軟體使用者，有另一條路徑拿得到。例外只免除這段文字本身要用真文字呈現的義務，不免除這則資訊要能被找到的義務。W3C 的規範本身有一句但書。只要同樣的資訊，除了圖片文字之外，也額外用真文字呈現一次，而且兩者都真的呈現給使用者看，這樣就符合規範。Google 的開發者文件也是同一個立場，真的必須把文字嵌進圖片，也要另外提供一份視覺障礙使用者用得到的說明。Otterly.AI 從 AI 搜尋這端給的建議，方向完全一致，圖片端的優化，像是檔名、替代文字、圖說，是文字內容的補充，不是替代品。
好不好看，從來不是判斷該不該把文字做成圖片的起點。真正該問的，是這段資訊有沒有其他管道找得到它，找不到，再漂亮的畫面也只是一塊裝飾。