Exchangeable Image File Format (EXIF) Viewer & Editor
Inspect EXIF metadata locally, flag location and device details, then export a stripped or selectively edited image with an auditable privacy score.{{ summaryHeading }} {{ summaryFigure }} {{ summaryLine }} {{ badge.text }}
| Signal | Detected | Triage | Export action | Copy |
|---|---|---|---|---|
| {{ row.label }} | {{ row.detected }} | {{ row.risk }} | {{ row.action }} |
| Field | Source value | Reviewed value | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.source }} | {{ row.reviewed }} |
| Item | Before | After export | Reason | Copy |
|---|---|---|---|---|
| {{ row.label }} | {{ row.before }} | {{ row.after }} | {{ row.reason }} |
| Version | Preview | File | Format | Dimensions | Size | Action | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.version }} | {{ row.filename }} | {{ row.format }} | {{ row.dimensions }} | {{ row.size }} | DownloadSource only |
A photograph can reveal more than its visible pixels. Cameras and phones often store Exchangeable Image File Format (EXIF) metadata alongside the image, including capture time, camera and lens names, orientation, software history, copyright text, and sometimes precise coordinates or equipment serial numbers.
That context can be valuable in a photo archive, evidence workflow, or asset catalog. The same fields can create privacy problems when an image is published, sent to a marketplace, or shared outside the team that collected it. Location data may identify a home or work site, while timestamps and serials can connect otherwise unrelated images.
| Metadata group | Useful context | Reason to review |
|---|---|---|
| GPS | Where the image was captured | May disclose a sensitive or private location |
| Date and time | Chronology and catalog sorting | May expose travel, routine, or incident timing |
| Camera, lens, and serials | Equipment tracking and technical diagnosis | May link images to a particular device or owner |
| Artist, copyright, description, and software | Ownership and processing history | May carry names, organizations, or private project notes |
| Orientation | Tells viewers how stored pixels should be rotated | Removing the tag without drawing upright pixels can make an export appear rotated |
Metadata is mutable. A correct-looking timestamp does not prove when a photograph was taken, and coordinates do not prove who held the camera. EXIF is supporting context, not a cryptographic record of authorship, custody, time, or place.
Stripping metadata is different from editing selected fields. A stripped export omits the EXIF block attached by the editor. A reviewed JPEG can instead keep a supported subset or write selected common fields.
Neither route preserves every vendor-specific tag, maker note, color-management detail, or archival property. Keep the original master separate from a sharing copy, even when the exported pixels look unchanged.
How to Use This Tool:
Choose the intended handoff first; privacy sharing, archival review, and editable JPEG workflows need different metadata policies.
- Drop, paste, or browse for one browser-decodable image up to 25 MiB. The source dimensions, readable tag count, and detected privacy categories appear after local inspection.
- Select the closest Workflow preset, then review its Output format and Metadata policy. Presets are starting points, not approval decisions.
- Use Strip all metadata for a sharing copy with no EXIF block attached by this editor. Use Keep supported original EXIF or Apply reviewed field edits only for JPEG output.
- Check Apply EXIF orientation and the exported preview. When upright pixels are drawn into a JPEG that still carries EXIF, enable Normalize Orientation tag to write Orientation 1 and avoid a second rotation.
- Review GPS and equipment serial settings before selecting Export reviewed image. Inspect the final preview, format, dimensions, byte size, change ledger, and privacy actions before replacing or sharing any file.
Interpreting Results:
The privacy score is a triage aid built from five detected categories. It helps prioritize review but does not declare an image safe to publish. Read the signal rows and planned export action, not the percentage alone.
- Metadata stripped means the new browser-encoded image receives no EXIF block from this editor. It does not certify removal of every possible non-EXIF metadata container or visible clue.
- Supported EXIF kept means only the common fields the JPEG writer understands are reconstructed. It is not a byte-for-byte copy of the source metadata.
- Reviewed EXIF written means blank editable fields are omitted and staged values are written where supported. Compare the change ledger with the intended handoff.
- Use the final preview to catch rotation or compression problems and the final byte count to understand the encoded copy. File-size change does not measure visual quality.
Technical Details:
EXIF is stored in structured image metadata, commonly inside JPEG application segments. Reading and writing are separate operations here: readable source tags populate a review model, while export builds a new pixel encoding and either omits EXIF or constructs a supported JPEG EXIF block.
Formula Core:
The triage score is the sum of fixed weights for detected categories. Each indicator equals 1 when that category is present and 0 when it is absent. The weights are a local review heuristic, not an EXIF standard or a probability of harm.
| Score | Band | Meaning |
|---|---|---|
| 0 | Clear | None of the five reviewed categories was detected |
| Greater than 0 and less than 15 | Low | Only a low-weight category was detected |
| 15 to 39 | Medium | One or more categories warrant deliberate review |
| 40 to 100 | High | GPS, or a combination totaling at least 40 points, was detected |
Byte-size change is calculated only after export as (output bytes − source bytes) / source bytes × 100. It may be negative or positive because format, quality, metadata, and the browser encoder all affect the new file.
Rule Core:
| Resolved output | Metadata policy | Export behavior |
|---|---|---|
| JPEG | Strip | Re-encode pixels without attaching an EXIF block |
| JPEG | Keep | Reconstruct supported common source fields, then apply GPS and serial removal settings |
| JPEG | Edit | Write nonblank reviewed fields, optional GPS, and optional duplicate digitized time |
| PNG or WebP | Any incoming choice | Force a metadata-stripped browser re-encode; JPEG-only EXIF writing is unavailable |
Auto format keeps JPEG, PNG, or WebP when the source already uses one of those formats; other browser-decodable inputs resolve to JPEG. Encoder quality ranges from 10% to 100% for JPEG and WebP. PNG uses the browser's lossless PNG encoding and ignores that control.
Transformation Core:
The image is decoded, drawn to a canvas at its source dimensions, and encoded into a new JPEG, PNG, or WebP. JPEG output uses a white background; PNG and WebP may retain alpha when the browser decoder and encoder support it. Applying EXIF orientation asks the decoder to draw the visually upright pixel arrangement before export.
GPS coordinates are staged as decimal degrees. When precision is set from 1 through 6, latitude and longitude are rounded to that many decimal places before conversion to EXIF degrees, minutes, and seconds. A setting of 0 keeps the available numeric precision. Both latitude and longitude must be valid before a GPS block is written; latitude is limited to −90 through 90 and longitude to −180 through 180.
A keep or edit export writes only supported common fields such as make, model, lens model, timestamps, artist, copyright, description, orientation, selected serials, and GPS. Unsupported tags and maker-specific data are not preserved automatically.
Privacy and Accuracy Notes:
The source image, decoded metadata, edits, and exported image remain in the browser tab; the page does not upload the file. A link opened from the GPS review is different: following it sends the chosen coordinates to that external mapping site.
Metadata detection depends on what the browser can decode and what the EXIF reader returns. A zero score can mean that none of the five categories was found, not that the file contains no metadata of any kind. Inspect the exported file with a second metadata viewer when publication risk is high.
Keep the original image as the archive master. Browser re-encoding can change compression, color handling, alpha behavior, and unsupported metadata even when pixel dimensions remain the same.
Worked Examples:
Preparing a public sharing copy
A phone photo contains GPS, capture time, and device details. Choose Public sharing · strip all metadata, export the image, and confirm that each detected category says it is removed from the export. Keep the original elsewhere because the sharing copy has been re-encoded.
Correcting a JPEG catalog record
For a JPEG that needs an updated artist and capture time, choose JPEG handoff · apply reviewed edits, change only those fields, and leave GPS and serial removal enabled unless the catalog requires them. Normalize Orientation only after confirming that the exported pixels are upright, then compare the change ledger with the catalog request.
References:
- CIPA DC-008-Translation-2026: Exif Version 3.1, Camera & Imaging Products Association, January 30, 2026.