An online EXIF editor is a browser page that reads the Exchangeable Image File Format metadata inside a JPEG, lets you change a defined set of text fields, and then produces a new JPEG file that you can download, with the edits written into a standard EXIF segment while the actual image bytes stay untouched. The term describes a deliberately small category of tools, not a full metadata suite, and the scope is part of why they exist. A page that promises to edit every camera, GPS, lens, and vendor record safely needs a format-aware merge policy for each kind of block; a page that only writes three well-documented credit fields can describe exactly what it changes and what it removes. The EXIF Editor follows the second pattern: it reads Description, Artist, and Copyright from a JPEG you pick in the browser, lets you type new values in printable ASCII text, and downloads a new file with a fresh standard APP1 EXIF block. Your photo never leaves the current tab. The compressed image scan and any JFIF segment are copied through, while the previous EXIF block is replaced rather than merged.
What an Online EXIF Editor Actually Does
EXIF is the Exchangeable Image File Format, a standard maintained by CIPA (the Camera & Imaging Products Association) that defines how cameras and phones can embed structured information inside the image files they produce. The most familiar fields are capture date, lens model, and ISO speed, but the same standard also reserves a small set of plain-text fields intended for human-readable credit information: an image description, an artist or creator name, and a copyright notice. These three text fields are the slice an online EXIF editor is typically built around, and they are the slice the EXIF Editor works with.
It helps to separate three terms that get mixed up in marketing copy. EXIF is one block format, defined by CIPA's Exif Version 3.1 standard, that lives inside the JPEG's APP1 application segment. IPTC is a separate block, originally from the newspaper world, that carries editorial captions and rights metadata. XMP is an Adobe-led XML-based sidecar format that can ride along inside a JPEG as another APP1 segment. A "metadata editor" label can refer to any of these, or all of them. An "online EXIF editor" is more specific: it touches the EXIF block only. The tool covered here is even narrower than that, because it is deliberately built to write the three IFD0 text fields and nothing else.
The Three Fields and Why This Scope Matters
Each JPEG that contains EXIF carries a small directory of tagged values, and three of those tags are the ones this tool reads and writes. Their CIPA-defined identifiers and the role each one plays are shown in the table below.
| EXIF tag | Tag ID (hex) | Byte limit | Intended use |
|---|---|---|---|
| ImageDescription | 0x010E | 120 bytes | Short factual note about the image |
| Artist | 0x013B | 120 bytes | Creator or credit line |
| Copyright | 0x8298 | 120 bytes | Year and rights holder notice |
The byte limits are not arbitrary. EXIF ASCII values are stored as NUL-terminated byte strings inside a TIFF container, and the focused writer on this page uses a deterministic byte representation that round-trips cleanly across the standard readers it targets. A long legal notice, names with accents, non-Latin text, control characters, or emoji cannot be represented safely by that representation, so the page rejects them rather than guessing an encoding and producing silent corruption. If the value you need is wider than 120 bytes or contains characters outside printable ASCII, the tool returns an error and the file is left unchanged. This is a deliberate design choice, not a missing feature.
A related decision is trimming. Leading and trailing whitespace is stripped from each field before the new EXIF block is built, so that a stray space typed into a form is not written into the record. At least one of the three fields must contain text, otherwise there is no input to embed and the tool refuses to produce an output.
How to Add Description, Artist, and Copyright in Your Browser
The procedure is short and runs entirely on the page in your current tab.
- Open the EXIF Editor and pick one JPEG from your computer. The file must be a real JPEG up to 25 MiB; PNG, WebP, HEIC, TIFF, RAW, or any non-JPEG renamed with a .jpg extension is rejected by the marker validator.
- The page reads the three supported text fields locally using the exifr library and displays any values already present. This is your chance to confirm what you are about to overwrite, because the next step replaces the existing EXIF block rather than merging into it.
- Type the new Description, Artist, or Copyright notice you want published, in printable ASCII only. You can fill any combination of the three; at least one must contain text.
- Select Write EXIF text. The page validates the JPEG marker stream, builds a new APP1 segment containing only the three text fields, copies the original compressed image scan and any JFIF APP0 segment through unchanged, and produces a downloadable JPEG in the current tab.
- Save the new file and reopen it in an independent metadata viewer, such as the EXIF Viewer, to confirm the fields you typed are now visible. If you do not see the values you expect, the source file may not have been a valid JPEG, the download may have been blocked by browser settings, or the destination application may strip metadata on import.
For a deeper walk-through specifically about the three text fields, the guide to set EXIF Description, Artist, and Copyright in a JPEG covers the same fields in a slightly different framing.
How the Local Writer Builds a Fresh EXIF Block
The output is a real JPEG, not a metadata sidecar and not a browser-only preview. To understand why the trade-offs exist, it helps to know what the local writer actually does once you click the button.
JPEG files are organised as a sequence of markers. Each marker is a two-byte code followed by a length-prefixed payload, and the markers before the SOS (Start Of Scan) marker carry the metadata, while the SOS marker and the bytes that follow it are the actual compressed image data. The CIPA-maintained EXIF standard defines how a TIFF header, a small set of Image File Directories (IFDs), and the tagged values inside them should be wrapped in an APP1 segment. The W3C's JPEG File Interchange Format specification, JFIF 1.02, defines the parallel APP0 segment that many tools use to mark a file as a JFIF JPEG.
The local writer on this page performs these steps:
- Validates the JPEG marker stream so that a truncated marker, an unrealistic length, or a renamed non-JPEG cannot reach the byte-writing stage.
- Retains any JFIF APP0 segment that was already present, because removing it would change the file's identity in downstream tools.
- Removes every existing EXIF APP1 segment, so that two conflicting sets of fields cannot end up in the same file.
- Builds a little-endian TIFF container with one IFD0 containing only the three supported tags, each holding a NUL-terminated printable-ASCII string.
- Inserts that new APP1 segment in the metadata block and copies the SOS marker and the compressed scan bytes through unchanged, without canvas decoding or re-encoding.
The result is a file whose visible pixels are byte-for-byte identical to the input and whose EXIF block is exactly the three fields you typed.
What Happens to Pixels, JFIF, and the Rest of the File
Because the writer works at the segment level rather than the pixel level, the scope of what changes is small and explicit.
| Element in the JPEG | Handled by the EXIF Editor |
|---|---|
| Compressed image scan (SOS and after) | Copied through unchanged |
| JFIF APP0 segment | Preserved when present |
| Existing EXIF APP1 segment | Replaced with a fresh block |
| GPS, capture date, lens, MakerNote blocks | Removed with the old EXIF block |
| Embedded EXIF thumbnail | Removed with the old EXIF block |
| IPTC and XMP blocks | Not touched; preserved if present |
| Pixel dimensions and quality | Not changed (no re-encoding) |
This is why the tool's documented contract is to "replace, not merge". A safe merge across every EXIF field requires vendor-specific knowledge — for example, MakerNote blocks from a Canon or Sony camera use proprietary binary layouts that cannot be safely edited byte by byte — so the page chooses to write only what it can write deterministically and to remove the rest. If your source file contains GPS, capture dates, or camera serial details that you need to keep, duplicate the original and run the credit-field writer on the copy while preserving the untouched master.
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.