Every image carries a second file inside it.

The picture is only half the file. The rest is a record: where the camera was, when the shutter opened, which software touched the image since. Some of it is useful, some of it is nobody's business — and all of it can be read.

• GPS coordinates, altitude and direction, when the camera recorded them.
• Capture and edit timestamps.
• Camera, lens, firmware and serial identifiers.
• Software history, which often names the editors a file has passed through.
• Author, copyright and description fields.
• Embedded thumbnails, carried separately from the main image.

One load returns EXIF, XMP, IPTC and PNG text together, with the image's own properties alongside. How you arrange it is up to you.

• Group by source to see which block wrote what, by category to read it in human terms, or as a flat list when you are hunting for one tag.
• Categories bucket EXIF into GPS, lens, device, camera, image, date-time, author and general.
• A tag summary and per-source counts tell you how much is in there before you start reading.
• Raw hex sits beside the decoded value for the tags where a string is not the whole story.

Writing metadata back is the part most formats make difficult. StegoPixel exposes a fixed whitelist of 18 typed EXIF tags and checks that a value matches the tag's declared type before it writes anything.

• Eight string tags cover the fields people reach for most — the chip row below names them.
• Three date/time tags: DateTimeOriginal, DateTimeDigitized and DateTime.
• Five numeric tags: XResolution, YResolution, ExposureTime, FNumber and ISOSpeedRatings.
• Two enumerated tags with constrained values: Orientation (1–8) and ResolutionUnit (1–3).
• Custom key/value pairs are written as XMP in a dedicated urn:stegopixel:custom namespace.
• Keys are validated — letters, underscores, dots and hyphens, up to 128 characters.

One image at a time is fine until it is not. The workbench is built so the second edit costs less than the first.

• Folder-scale work runs through the metadata workflow nodes: Metadata_Read, Metadata_Write, Metadata_Remove and Metadata_Validate.
• A write node applies a saved template or raw JSON entries to every file it sees.

Values do not have to be impossible to be suspicious. The inconsistency check looks for dates that do not line up, metadata chains that are missing, and edit-history evidence sitting in plain sight.

• A capture date before 1970, or in the future, is flagged as serious.
• A capture date more than a year away from the file's modified date reads as a conflict.
• A file with no EXIF, XMP, IPTC or PNG text at all is flagged as a missing chain.
• A JPEG with no camera identity, or an XMP block with no EXIF behind it, earns a second look.
• An editor's name in the Software tag registers as low-severity edit-chain evidence.

A few facts worth holding onto before a metadata session becomes a habit.

• Strip-all removes EXIF, XMP and IPTC and re-saves the file behind a confirmation dialog.
• Custom key/value tags need an XMP-capable format; GIF and BMP are skipped with a warning.
• EXIF writes cover JPEG, PNG, TIFF and WebP — GIF and BMP cannot carry EXIF at all.
• Reading is never restricted by writing: the full record stays inspectable and exportable, whatever the format allows.
• HEIC, AVIF and camera RAW files appear in the format catalogue but cannot be opened — the decoder handles JPEG, PNG, TIFF, WebP, GIF and BMP.

Frequently asked questions