線上 EXIF 編輯器是一種瀏覽器頁面，會讀取 JPEG 內部的可交換影像檔案格式 (Exchangeable Image File Format) 中繼資料，讓您修改一組預先定義的文字欄位，然後產生一個可供下載的新 JPEG 檔案，其中的編輯內容會寫入標準的 EXIF 區段，而實際的影像位元組則保持不動。這個詞彙描述的是一類刻意精簡的工具，而不是一套完整的中繼資料套件，而這個範圍正是它們存在的部分原因。一個承諾能安全編輯所有相機、GPS、鏡頭與廠商記錄的頁面，需要為每一種區塊制定一個具備格式感知能力的合併政策;而一個只寫入三個有完善文件記載的著作權欄位的頁面，則可以清楚說明它修改了什麼、移除了什麼。EXIF 編輯器採取的是第二種模式:它從您在瀏覽器中挑選的 JPEG 讀取描述、作者與著作權，讓您以可列印 ASCII 文字輸入新值，然後下載一個含有全新標準 EXIF APP1 區段的檔案。您的照片從未離開目前的分頁。壓縮的影像掃描資料以及任何 JFIF 區段都會原封不動地複製過去，而先前的 EXIF 區段則會被整個替換，而非合併。
線上 EXIF 編輯器實際上做了什麼
EXIF 是可交換影像檔案格式 (Exchangeable Image File Format)，這套標準由 CIPA(日本相機與影像產品協會)負責維護，規範相機和手機應如何在其所產生的影像檔案中嵌入結構化資訊。最常見的欄位包括拍攝日期、鏡頭型號與 ISO 速度，但同一套標準也保留了少量純文字欄位，供人類可讀的著作權資訊使用:影像描述、作者或創作者姓名，以及著作權聲明。這三個文字欄位是線上 EXIF 編輯器通常圍繞建立的範圍，也是本 EXIF 編輯器所處理的範圍。
區分三個常在行銷文案中被混用的詞彙會有所幫助。EXIF 是一種區塊格式，由 CIPA 的 Exif 3.1 版標準所定義，存在於 JPEG 的 APP1 應用區段中。IPTC 是另一種獨立的區塊，源自報業世界，用於承載編輯註解與權利中繼資料。XMP 是由 Adobe 主導、以 XML 為基礎的側車檔案格式，可以另一個 APP1 區段的形式隨附於 JPEG 之中。「中繼資料編輯器」這個標籤可能指其中任一種，或三者皆是。「線上 EXIF 編輯器」則更明確:它只會動到 EXIF 區塊。本篇介紹的工具範圍甚至更小，因為它刻意只寫入三個 IFD0 文字欄位，除此之外什麼都不寫。
這三個欄位，以及為何這個範圍很重要
每張含有 EXIF 的 JPEG 都帶有一個小型的標籤值目錄，而其中三個標籤正是本工具會讀取與寫入的對象。下表列出它們由 CIPA 定義的識別碼，以及各自扮演的角色。
| EXIF 標籤 | 標籤 ID (十六進位) | 位元組上限 | 預期用途 |
|---|---|---|---|
| ImageDescription | 0x010E | 120 個位元組 | 關於影像的簡短客觀說明 |
| Artist | 0x013B | 120 個位元組 | 創作者或著作權署名 |
| Copyright | 0x8298 | 120 個位元組 | 年份與權利人聲明 |
這些位元組上限並非任意制定。EXIF 的 ASCII 值是以 NUL 結尾的位元組字串儲存於 TIFF 容器之中，而本頁面所採用的精簡寫入器使用一種決定性的位元組表示方式，能夠在其所瞄準的標準讀取器之間乾淨地往返 (round-trip)。較長的法律聲明、帶有腔調符號的名字、非拉丁文字、控制字元或表情符號，都無法由這種表示方式安全地表達，因此頁面會直接拒絕，而不是去猜測一個編碼方式並產生靜默的損毀。如果您需要寫入的值寬度超過 120 個位元組，或包含可列印 ASCII 以外的字元，工具會回傳錯誤，而檔案則保持不變。這是一項刻意的設計選擇，而不是一項尚未實作的功能。
另一項相關的決定是修剪。在建立新的 EXIF 區段之前，每個欄位的前後空白都會被去除，如此一來，表單中不小心打出的多餘空白就不會被寫入記錄之中。三個欄位中至少必須有一個含有文字，否則就沒有內容可嵌入，工具也會拒絕產生輸出。
如何在瀏覽器中加入描述、作者與著作權
操作流程很短，且完全在您目前分頁的頁面中執行。
- 開啟 EXIF 編輯器，並從您的電腦中挑選一個 JPEG 檔案。該檔案必須是真正的 JPEG，大小上限為 25 MiB;PNG、WebP、HEIC、TIFF、RAW，或任何被重新命名為 .jpg 副檔名的非 JPEG 檔案，都會被標記驗證器拒絕。
- 頁面會使用 exifr 函式庫在本機讀取三個支援的文字欄位，並顯示任何已存在的值。這是您確認即將覆寫內容的機會，因為下一步會直接替換既有的 EXIF 區段，而非合併進去。
- 輸入您希望寫入的新描述、作者或著作權聲明，僅限可列印 ASCII。您可以填入這三個欄位的任意組合，但至少必須有一個含有文字。
- 選擇「寫入 EXIF 文字」。頁面會驗證 JPEG 的標記串流，建立一個只包含這三個文字欄位的新 APP1 區段，將原始的壓縮影像掃描資料以及任何 JFIF APP0 區段原封不動地複製過去，並在目前分頁中產生一個可供下載的 JPEG。
- 儲存新檔案，並在獨立的中繼資料檢視器(例如 EXIF 檢視器)中重新開啟，以確認您輸入的欄位現已可見。如果您沒有看到預期的值，來源檔案可能不是有效的 JPEG、下載可能被瀏覽器設定擋下，或是目的端應用程式在匯入時移除了中繼資料。
若想深入了解專門針對這三個文字欄位的操作流程，在 JPEG 中設定 EXIF 描述、作者與著作權的指南從略微不同的角度涵蓋了相同的欄位。
本機寫入器如何建立全新的 EXIF 區段
輸出是一個真正的 JPEG，而非中繼資料側車檔案，也非僅供瀏覽器預覽。要理解這些取捨為何存在，值得先了解按下按鈕後，本機寫入器實際上做了什麼。
JPEG 檔案是以一序列的標記 (marker) 來組織的。每個標記都是一個兩位元組的代碼，後面接著一個帶有長度前綴的承載資料;SOS(Start Of Scan，掃描起始)標記之前的標記承載的是中繼資料，而 SOS 標記本身以及其後的位元組則是實際的壓縮影像資料。由 CIPA 維護的 EXIF 標準定義了 TIFF 標頭、一組小型影像檔案目錄 (IFD)，以及其中的標籤值應如何被包裝進 APP1 區段。W3C 的 JPEG 檔案交換格式規範，JFIF 1.02，則定義了許多工具用來將檔案標記為 JFIF JPEG 的對應 APP0 區段。
本頁面上的本機寫入器會執行以下步驟:
- 驗證 JPEG 的標記串流，使截斷的標記、不合理的長度，或是被重新命名的非 JPEG 檔案都無法進入實際寫入位元組的階段。
- 保留任何原本就存在的 JFIF APP0 區段，因為移除它會改變下游工具對該檔案身分的識別結果。
- 移除所有既有的 EXIF APP1 區段，以免兩組互相衝突的欄位同時出現在同一個檔案中。
- 建立一個位元組由低到高位元組序 (little-endian) 的 TIFF 容器，內含單一個 IFD0，其中只放三個支援的標籤，每個標籤各儲存一個以 NUL 結尾的可列印 ASCII 字串。
- 將這個新的 APP1 區段插入中繼資料區塊，並將 SOS 標記及壓縮掃描位元組原封不動地複製過去，不進行畫布解碼或重新編碼。
其結果是一個可見像素與輸入檔案逐位元組完全相同，且其 EXIF 區塊恰好就是您輸入的三個欄位的檔案。
像素、JFIF 與檔案其他部分會發生什麼事
由於寫入器是在區段層級而非像素層級運作，因此變動的範圍很小且明確。
| JPEG 中的元素 | EXIF 編輯器的處理方式 |
|---|---|
| 壓縮影像掃描 (SOS 及其後) | 原封不動地複製過去 |
| JFIF APP0 區段 | 若存在則予以保留 |
| 既有的 EXIF APP1 區段 | 以全新的區塊取代 |
| GPS、拍攝日期、鏡頭、MakerNote 區塊 | 隨舊的 EXIF 區塊一併移除 |
| 內嵌的 EXIF 縮圖 | 隨舊的 EXIF 區塊一併移除 |
| IPTC 與 XMP 區塊 | 不處理;若存在則予以保留 |
| 像素尺寸與品質 | 不變更 (未重新編碼) |
這正是為什麼本工具所記載的合約是「取代，而不合併」。要對每個 EXIF 欄位都進行安全合併，需要具備廠商專屬的知識 — 例如 Canon 或 Sony 相機的 MakerNote 區塊採用專有的二進位配置，無法逐位元組安全編輯 — 因此本頁面選擇只寫入它能夠以決定性方式寫入的內容，並將其餘部分移除。如果您的來源檔案中含有您需要保留的 GPS、拍攝日期或相機序號資訊，請複製原始檔，並在副本上執行著作權欄位寫入器，同時保留未經修改的母檔。
Limits That Decide Whether This Tool Fits Your Job
Several limits govern when the tool will help and when it will not, and they are worth checking before you start.
The file must be a JPEG. PNG, WebP, HEIC, TIFF, RAW, live photos, and images embedded in Office documents or PDFs are outside the tool's scope, because the EXIF standard applies to JPEG (and a handful of TIFF-derived formats) and the writer validates the JPEG marker stream specifically. The file must also be at most 25 MiB, which keeps the in-browser memory footprint reasonable.
The fields must be printable ASCII. Any character that is not in the printable ASCII range is rejected rather than mis-encoded. Each field is capped at 120 bytes, so a multi-paragraph rights statement will not fit. If your real-world attribution includes accented names, a longer notice, or a Creative Commons identifier with symbols, you will need a separate workflow — for example, an IPTC or XMP block written by a tool that supports UTF-8. The page does not create a licence, register a work, or add a visible watermark, and it is not a substitute for legal advice.
The output is not a privacy tool in the broader sense. It writes credit fields and removes the old EXIF block, but it does not target IPTC, XMP, or non-EXIF segments specifically. The CIPA standard defines the EXIF block; other application segments in the same JPEG carry their own data and are passed through unchanged. If you need to scrub GPS coordinates that live outside EXIF, or if you need to convert the file format before sharing, a different tool in the same browser-based family handles each case. The EXIF Viewer at /image/exif-viewer/ lets you read what is in the file before you change it, and the broader set of local image tools covers the rest.
A final limit is the absence of enforcement. A Copyright field that contains a year and rights holder is a text label. Platforms can strip metadata on upload, viewers can ignore it, and the field does not by itself prove authorship, prevent copying, or make any destination display the credit. If attribution matters legally, keep a separate rights record and verify that the destination application actually surfaces the EXIF fields you have written.
If you're weighing options, Remove EXIF Data Explained: What Gets Stripped From Photos covers this in detail.