← Back to Blog

Media Metadata Explained

Understand the difference between attachment post fields, post meta, generated image metadata and embedded file metadata.

Veyra Admin

5 min read

  • Guide
  • Intermediate
  • 5 minutes read
  • Reviewed August 5, 2026
  • WordPress media

WordPress media metadata exists in several layers.

An attachment has ordinary post fields, attachment-specific post meta, image sub-size data and sometimes information read from EXIF or IPTC metadata embedded in the source file.

Attachment Post Fields

As an attachment post, a media item can use fields such as:

  • ID.
  • Title.
  • Content or description.
  • Excerpt or caption.
  • Author.
  • Date.
  • Status.
  • Parent post.
  • MIME type.
  • GUID and permalink-related data.

Alternative text for images is stored separately as attachment post meta.

File Path and Attachment Metadata

WordPress stores the relative uploaded-file path and, for images and some media types, a metadata array.

Image attachment metadata can include:

  • Width and height.
  • Original filename information.
  • Generated sub-size filenames and dimensions.
  • Image format details.
  • File size information in modern versions.
  • Camera or descriptive image metadata when available.

Developers should use WordPress APIs rather than assuming the serialized structure will never evolve.

EXIF and IPTC

WordPress can read selected EXIF and IPTC fields from supported image files, including camera details, dates, credit, caption, copyright and title information.

Some values may be used as defaults during attachment creation. This can accidentally expose location, authorship or internal production information if the workflow does not review embedded metadata.

Metadata Privacy

Source photographs can contain sensitive metadata such as capture time, camera details or location. Generated image derivatives may strip much of this metadata depending on the processing path and current WordPress configuration, while the original file may retain it.

Establish a policy for:

  • Removing sensitive metadata before upload.
  • Preserving copyright and colour-profile data where required.
  • Retaining originals outside public storage.
  • Reviewing client-side and server-side image processing.

Custom Metadata

Plugins can add attachment post meta for licensing, photographers, DAM identifiers, focal points, remote-storage keys, transcripts or workflow status.

Use stable keys, validation, sanitization, capability checks and a documented uninstall policy. Do not overload the visible caption or alt text with administrative information.

Metadata During Migration

Copying only the uploads directory does not recreate attachment posts or metadata. Exporting only database records without files leaves broken references.

A complete migration preserves:

  • Attachment IDs or mapping.
  • Original and generated files.
  • Attachment fields and post meta.
  • Parent or relationship data.
  • Content references.
  • Remote-storage configuration.

Developers and APIs

Useful APIs include functions for retrieving attachment metadata, image sources, alt text and generated sizes. The REST API exposes media records according to permissions and schema.

Avoid parsing raw serialized metadata when a core API provides the required information.

Frequently Asked Questions

Is alt text stored inside the image file?

WordPress normally stores attachment alt text in post meta, not as the file's embedded EXIF description.

Does copying uploads preserve the Media Library?

No. The database attachment records and metadata are also required.

Can plugins add metadata to attachments?

Yes. Attachments can use post meta like other post types.

Applying Media Metadata Explained in a Real WordPress Project

Consider the source asset, WordPress attachment record, generated files and every public use of the media. Accessibility, licensing, storage, performance and deletion safety should be reviewed together.

A connected concept is Understanding the WordPress Media Library. Reading the two together helps separate the immediate task from the wider WordPress responsibility.

A useful implementation begins by writing down the current state, the intended outcome and the evidence that will prove the change worked. This prevents a configuration screen, plugin recommendation or code snippet from becoming the entire strategy.

A Practical Example

Imagine a team making this decision for a production WordPress site. The useful question is not only “Can WordPress do this?” but “Which layer owns it, who maintains it, what data does it affect and how will we verify it after an update?”

Write the answer in operational terms. Name the content, user, setting, file, API or service involved. Then identify what should remain true if the theme changes, a plugin is replaced or the site is migrated.

Questions to Ask

  • What user or system problem does this solve?
  • Which WordPress layer owns the behaviour?
  • What data is created or changed?
  • Who may perform the action?
  • What can fail, and how will that failure be visible?
  • How is the result tested after updates?
  • What is the migration or removal path?

Follow the Complete Media Lifecycle

A media decision begins with the source file and continues through upload, attachment metadata, generated derivatives, delivery, reuse, replacement and deletion.

Review visual quality, accessibility text, licensing, dimensions, file weight, cache behaviour and every place the asset is referenced. WordPress can track an attachment record, but it cannot always identify every use created by themes, custom fields or external systems.

Model Meaning Before Interface

Start with the information and its lifecycle, not the plugin screen. Decide whether a value represents an object, classification, attribute or relationship.

Use stable machine keys, human labels and documented formats. A maintainable model explains how data is validated, queried, displayed, exported and retired.

Official Reference Context

The WordPress Media Library Documentation is the primary version-specific reference for this topic. Use the current documentation to verify interface labels, supported APIs and behaviour before applying instructions to a production site.

How to Verify the Result

  • Check the original file, generated sizes and frontend delivery.
  • Verify alternative text, captions, credits and direct-file visibility.
  • Search for references before replacing or deleting the attachment.

Sources and Further Reading

Continue Learning