Check image copyright metadata and creator fields

It recognizes common field spellings, qualified XMP names, and nested metadata objects without reading or changing the image itself. The result identifies which field paths matched and which required category is missing, making it suitable for a quick manual review or a repeatable publishing check before delivery.

Check the metadata before an image is published

Copyright information is useful only when it travels with the asset and can be found by the systems that catalog, license, or publish it. This checker gives you a focused preflight test for two fundamental categories: a copyright or rights statement and a creator attribution. Supply the metadata block already extracted from the image, and the result reports whether each category has at least one populated value. It also lists the exact paths that matched, so a reviewer can see whether the evidence came from a flat IPTC property, a qualified XMP key, or a nested object. The check is intentionally narrow. It does not claim that a statement is legally sufficient, verify that the named creator owns the work, or determine licensing terms. Instead, it answers a practical production question consistently: did the exported metadata retain usable copyright and creator fields? That makes it easy to place before upload, delivery, syndication, or archival steps where missing attribution would otherwise be noticed too late.

How common IPTC and XMP names are interpreted

Metadata libraries expose the same concepts in different shapes. One extractor may return keys such as CopyrightNotice and By-line, another may return dc:rights and dc:creator, and a third may group properties below iptc, xmp, dc, or photoshop objects. The checker normalizes capitalization and punctuation while preserving the original matched path in its output. A string counts as populated only when it contains non-whitespace text. An array counts when at least one member is populated, which accommodates XMP creator sequences and rights alternatives. Nested objects are inspected recursively in a deterministic key order. Numbers, booleans, empty strings, empty arrays, and objects without textual values do not satisfy either requirement. Some credit-related fields are recognized because real export tools use them for attribution, but the output remains transparent: matched_fields shows exactly what caused a positive result. If your organization requires a smaller approved field set, use those paths in a separate policy check rather than treating this presence test as a full metadata conformance profile.

Understand missing blocks, missing values, and the result

There is an important difference between metadata that was not supplied and metadata that was supplied but lacks the requested fields. If the metadata block is absent or null, the request fails with an invalid input error because there is nothing to inspect. An explicitly supplied empty object is valid input and produces a normal result with both categories listed in missing_fields. That distinction helps automation separate an extraction or integration failure from an image that genuinely contains no attribution fields. The valid flag is true only when both copyright_present and creator_present are true. Each boolean can still be used independently when your workflow permits one category to be repaired later. The checker does not fetch an image, parse binary JPEG or TIFF segments, write tags, contact a registry, or retain the submitted object. Extract metadata with your preferred imaging tool first, then send the resulting object here. At $0.002 per API request, it can serve as a small deterministic gate in asset ingestion, export validation, or content delivery pipelines.