Embedded metadata is metadata automatically baked into a file by the software that created it, such as a photo's format, resolution, and capture date. It is not the same as custom metadata, which a person adds afterward; embedded metadata is written into the file at creation and travels with it across systems.
Why it matters
Because it cannot be separated from the file, embedded metadata survives migration and copying and is readable by a wide range of software. That durability is its strength, and it is also why embedding the custom metadata you add later matters: anything not embedded can vanish when you change platforms.
How it shows up in practice
Shoot a photo on an iPhone and the file already carries location, date, time, and facial grouping. A DSLR writes resolution, size, exposure, and lens data. Open any of these in Adobe Bridge or Photo Mechanic and you can read the embedded fields directly. The limitation is that this technical data is rarely what people search by: a channel manager looks for subject, campaign, usage rights, and creator, not f-stop. That gap is exactly what custom metadata fills, which is why most libraries use both.
Common mistakes
- Relying on embedded technical metadata to organize a library that people search by topic.
- Assuming camera-generated file names are descriptive enough to find assets later.
- Adding custom metadata only inside a platform so it never embeds on the file.
- Stripping embedded metadata during export or optimization without realizing it.
Stacks compares the two types in embedded vs. custom metadata.