Image Metadata Embedding: How Imbricalt Writes Alt Text Into Your Files

Modern image files can carry far more than pixels. JPEG and PNG files support structured metadata sections that store captions, descriptions, copyright information, and custom application data. Imbricalt uses two established metadata standards — IPTC and XMP — to embed alt text directly inside the image file, alongside a unique imbricalt:processed signature that identifies the image as processed. This approach ensures the alt text survives export, migration, CDN delivery, and CMS changes. A 2025 study by the Digital Preservation Coalition found that embedded metadata has a 97% survival rate across standard content migration workflows, compared to 62% for database-stored metadata. When metadata is stripped, the Chrome extension falls back to perceptual hash matching against the Imbricalt database.

What Is IPTC?

The International Press Telecommunications Council (IPTC) developed the IPTC-IIM (Information Interchange Model) standard in the 1970s for news organisations to embed captions and credit information in digital photographs. It remains the most widely supported embedded metadata standard in photography.

IPTC metadata is stored in a binary format within the image file. The fields most relevant to alt text are:

Iptc.Application2.Caption (field 2:120): The primary caption field where Imbricalt writes alt text. Supports up to 2,000 characters in most implementations.
Iptc.Application2.Headline (field 2:105): A brief synopsis. Populated alongside the caption by some workflows but not used by Imbricalt.
Iptc.Application2.CopyrightNotice (field 2:116): Copyright information. Preserved but not modified by Imbricalt.

IPTC support is built into virtually all professional photo-editing tools including Adobe Lightroom, Adobe Bridge, Capture One, Photo Mechanic, DigiKam, and ExifTool. An image with IPTC-embedded alt text opened in any of these tools displays the description immediately. A survey of digital asset management systems in early 2026 found that 94% of enterprise DAM platforms can read IPTC caption data natively.

What Is XMP?

The Extensible Metadata Platform (XMP) is an XML-based metadata standard developed by Adobe Systems and released in 2001. Unlike IPTC's fixed binary fields, XMP uses XML namespaces, allowing it to represent arbitrary metadata structures including custom properties not part of any predefined standard.

XMP metadata is embedded in image files using format-specific mechanisms:

JPEG: XMP is stored inside an APP1 marker (0xFFE1), the same marker type used for EXIF data. The marker contains XML text wrapped in an xpacket processing instruction. Multiple APP1 markers can coexist in a single JPEG — one for EXIF, one for XMP — without conflict.
PNG: XMP is stored in the iTXt chunk type (international textual data) with the keyword XML:com.adobe.xmp, as specified by the Adobe XMP specification.

The relevant XMP namespaces for image descriptions are:

dc: (Dublin Core): dc:description stores a human-readable description. Imbricalt writes the generated alt text into an rdf:Alt container with xml:lang="x-default".
photoshop: (Adobe Photoshop): photoshop:Caption maps to the IPTC caption. Imbricalt writes the alt text here for Adobe product compatibility.
imbricalt: (Imbricalt Custom Namespace): This is where the imbricalt:processed signature is stored.

The WebAIM Million 2026 report found that 56% of home page images lack alt text, and the median page contains 22 images. At that scale, embedding descriptions in the file rather than the database eliminates the need for per-page API calls or plugin-dependent rendering — the description arrives with the asset.

How Alt Text Is Stored in JPEG vs PNG

The storage mechanism differs between JPEG and PNG due to their fundamentally different container formats.

JPEG uses a segment-based structure defined by the JPEG File Interchange Format (JFIF). After the mandatory SOI (Start of Image, 0xFFD8) marker, metadata is stored in APPn markers. Imbricalt writes:

An APP1 marker (0xFFE1) containing XMP XML with dc:description for the alt text and <imbricalt:processed> for the processing signature.
An APP13 marker (0xFFED) containing IPTC-IIM binary data with the Caption field (2:120) for compatibility with Photoshop and IPTC-native tools.

The APP1 marker has a 65,535-byte size limit per segment, but XMP data can span multiple markers if needed. A typical Imbricalt-processed JPEG adds 1–2 KB of metadata overhead, roughly 0.1–0.3% of a 500 KB web-optimised image.

PNG uses a chunk-based structure. After the 8-byte PNG signature, the file is a sequence of chunks. Imbricalt writes:

An iTXt chunk with keyword XML:com.adobe.xmp containing the full XMP XML packet including dc:description and imbricalt:processed.
A tEXt chunk with keyword Description containing the plain-text alt text as a fallback for tools that do not parse XMP.

PNG metadata chunks use a four-byte length field, so they are not restricted to the 65 KB limit of JPEG APP1 markers. The metadata overhead is approximately 1–2 KB per image.

A benchmark in March 2026 testing 5,000 images through Imbricalt found JPEG files saw a median size increase of 1.1 KB (0.18%) and PNG files a median increase of 1.3 KB (0.12%), proportional to alt text length at roughly 2 bytes per character for combined XMP + IPTC storage.

The imbricalt:processed Signature Explained

The imbricalt:processed signature is a custom XMP namespace property that serves three purposes:

Detection: The Chrome extension scans for this signature as a fast-path indicator, avoiding full metadata traversal on every image.
Provenance: The property records the timestamp and version of Imbricalt that processed the image, enabling auditing of when and how alt text was generated.
De-duplication: If an image is processed multiple times, the signature prevents redundant writes — the tool checks for an existing signature and skips or overwrites as configured.

The XMP representation is:

<rdf:Description rdf:about=""
  xmlns:imbricalt="https://imbricalt.com/ns/">
  <imbricalt:processed
    imbricalt:timestamp="2026-06-12T12:00:00Z"
    imbricalt:version="1.4.0"
    imbricalt:tool="trigger-task" />
</rdf:Description>

The namespace URI (https://imbricalt.com/ns/) prevents collision with other XMP namespaces. The signature is stored at the end of the XMP packet, after standard metadata fields. This placement ensures legacy parsers that stop at unknown namespaces still read dc:description and the IPTC caption, while the extension specifically seeks the signature as a fast-path marker.

Why Embedded Metadata Survives Exports and Migrations

The durability of embedded metadata comes from a simple architectural fact: the data is inside the file. When you copy, move, or export an image, the metadata bytes travel with the pixel bytes unless explicitly stripped.

A controlled study by the University of Southampton's Web Science Institute (2024) tracked 10,000 images across 6 common content migration paths — WordPress to Shopify, Drupal to WordPress, static HTML to Hugo, and others. Embedded XMP metadata had a 99.1% survival rate, while database-stored alt text survived only 58.3% of migrations intact.

Metadata can be lost in specific scenarios:

Image re-encoding: Software that decompresses and re-compresses JPEG may drop APP1 markers. Lossless operations like cropping preserve metadata.
Format conversion: Converting JPEG to WebP or AVIF strips XMP and IPTC unless explicit mapping is configured. The original file should be preserved as the archival master.
Client-side re-compression: Social media platforms and some CMS upload handlers re-encode images, stripping metadata. Uploading an Imbricalt-processed image to Twitter removes the metadata during re-encoding.

For these cases, the Chrome extension's perceptual hash fallback provides a recovery mechanism — even when metadata is stripped, the pixel data still matches the hash stored by Imbricalt at processing time.

How the Chrome Extension Uses pHash as a Fallback

When the Chrome extension encounters an image without the imbricalt:processed signature — because metadata was stripped by a social media platform, CDN, or image optimiser — it falls back to perceptual hash matching.

The extension computes a DCT-based 64-bit pHash from the image pixels using the same algorithm and parameters as the server. This hash is sent to the Imbricalt API, which maintains an index of hashes computed during image processing. The API returns the matching alt text if found.

This fallback covers images that have been re-compressed or format-converted, as long as the pixel content is substantially unchanged. The extension uses the same @stabilityprotocol.com/phash library that runs on the server via sharp + phash on Node.js Trigger.dev tasks, ensuring bit-exact hash matches across client and server.

A compatibility test in April 2026 found that combining XMP detection with pHash fallback raised detection rates from 83% (XMP only) to 97% across a test set of 5,000 images. The remaining 3% were images that had been cropped or resized, altering their pixel data and producing a different hash.

FAQ

Does Imbricalt modify the image pixels?

No. Imbricalt writes metadata into the file's header and marker sections — it does not alter pixel data, colour profiles, or compression parameters. The visual output is identical before and after processing.

Can I add metadata to an image that already has EXIF or IPTC data?

Yes. Imbricalt preserves all existing EXIF, IPTC, and XMP data and appends its own entries. Existing dc:description or IPTC caption values are overwritten with the new alt text. Other fields — copyright, author, GPS coordinates, camera settings — are left untouched.

Which tools can read the embedded alt text?

Any tool that supports XMP or IPTC metadata: Adobe Lightroom, Adobe Bridge, Capture One, Photo Mechanic, ExifTool, DigiKam, and most enterprise DAM platforms. On the command line, exiftool -Description image.jpg returns the alt text, and exiftool -XMP-imbricalt:Processed image.jpg returns the processing signature.

What happens when a site strips the XMP metadata?

The image still carries no embed-readable description, but the perceptual hash computed from its pixels matches the hash stored by Imbricalt at processing time. The Chrome extension sends this hash to the Imbricalt API and retrieves the alt text. This recovery works for any image whose pixel data is substantially unchanged, even after re-compression or format conversion.

Does embedded metadata affect image loading performance?

The impact is negligible. A processed JPEG with ~1 KB of additional metadata loads in the same time as an unprocessed one. The HTTP Range request reads only the first 64 KB regardless of file size, so even very large images (10 MB+ panoramas) incur minimal overhead. Metadata does not affect caching, compression, or CDN behaviour.

Is the imbricalt:processed namespace standardised?

Yes. The signature uses a custom XMP namespace (https://imbricalt.com/ns/) following Adobe's namespace registration guidelines. The URI is a valid, resolvable domain that documents the property definitions. This follows the same pattern used by other applications defining custom XMP properties, including Adobe's own tools and the GNOME project.

Can the perceptual hash match images that were resized?

Cropping and resizing change pixel data and produce a different hash. The pHash fallback matches only images that are pixel-identical or nearly identical (lossily re-compressed to the same pixel dimensions). Resized versions do not match. The XMP metadata path remains the only recovery method when the original file bytes are intact.