Microsoft Image Creator, Paint and Designer: what Content Credentials they add and how a checker reads them
Microsoft says it has implemented Content Credentials, based on the C2PA standard, in Image Creator in Paint, Designer and Bing Image Creator. Both Image Creator files we hold have a record whose certificate names "Microsoft Corporation". Our checker reads them as a legacy trust-list match, because in our copies only the frozen Interim Trust List vouches for that signer.
Do Microsoft Image Creator, Paint and Designer add Content Credentials?
Microsoft says so on its own pages. The table gives Microsoft's statements in our own words. None of the first three pages shows a date for the statement.
| Product | What Microsoft says |
|---|---|
| Image Creator in Paint | Per Microsoft's Paint help page, images made with Image Creator or any other AI feature in Paint "will contain C2PA manifest". |
| Designer | Per Microsoft's Designer FAQ, Microsoft has implemented content credentials, based on the C2PA standard, for images created with Designer's editing features. The page also says all images generated with AI features in Designer have metadata attached that identifies the source, and that the provenance metadata can be viewed on the Content Credentials site. |
| Bing Image Creator | Per Microsoft's Bing Image Creator feature page, for each image created with Bing Image Creator, a watermark appears in the bottom left corner of the image. The page adds that Microsoft has also implemented content credentials and provenance based on the C2PA standard. |
| Azure OpenAI (a developer service) | Per Microsoft Learn, all AI-generated images from the service include Content Credentials. The manifest carries the description "AI Generated Image", and the verification tool shows them as issued by Microsoft Corporation. |
The Azure row is a separate product. None of the pages we opened says which certificate signs the consumer tools' records, or what happens to the record when a file is exported or shared. We do not check visible marks, so we say nothing about the Bing watermark in our files.
What is inside the Image Creator files we hold?
We hold two real files filed in the Wikimedia Commons category "Images generated by Image Creator by Microsoft Bing". Third parties uploaded them, and we cannot know how each file was handled before upload. They show what our checker reads in files we hold, not what any Microsoft product does every time.
Both files carry one signed record. In each, the record says:
- The signing certificate names "Microsoft Corporation", and the signing time is on June 8, 2026 (UTC).
- The claim generator is named "Microsoft Responsible AI Image Provenance".
- One action, "c2pa.created", with the software agent "Image Creator from Designer".
- The digital source type trainedAlgorithmicMedia. The IPTC vocabulary defines it as media created algorithmically using an AI model trained on captured content.
In both files the signature checks out and the image data matches the record. These are statements by the signer, not findings of ours.
Why does our checker call it a legacy trust-list match?
The Content Authenticity Initiative's trust list page says the Interim Trust List was frozen as of January 1, 2026, with no new certificates added. It says that during the transition period a validator may consult both that list and the C2PA Trust List, but must distinguish credentials signed under each. We load both and keep the answers apart.
Here is what each pass said about the Microsoft files.
| Trust list | Validator result | Date of our copy | Certificates in our copy | Naming Microsoft |
|---|---|---|---|---|
| C2PA Trust List, signer anchors | Invalid: signingCredential.untrusted and signingCredential.invalid | October 17, 2026 | 32 | 0 |
| Interim Trust List, anchors | Trusted | January 8, 2026 | 27 | 5 |
The last column counts certificates whose subject names Microsoft Corporation; we read the subjects on October 30, 2026 from copies fetched October 27, 2026. The two codes come from C2PA Specification 2.2, section 15.7. It uses signingCredential.untrusted when the chain of trust cannot be verified, and signingCredential.invalid when the credential is not acceptable under the requirements of its type. We report the codes as the validator gave them and do not state a cause.
Our measured result. Both Microsoft Image Creator files we hold read "Invalid" on the current C2PA Trust List and "Trusted" on the frozen Interim Trust List. The checker shows "Content Credentials found; legacy trust-list match" for both. Our accuracy page lists both real files and the changed copy described below. A list change would change this result, and a signer added after the date of our copy is not recognized until we fetch the list again.
What happens when the image changes?
We changed 12 image-data bytes of one of the two Microsoft files. The checker reads the changed file as "Content Credentials failed validation", because the image no longer matches the signed record. That was one test on one file.
In a second test, we redrew each real file that carries a record (nine files, including both Microsoft files) through a browser canvas and saved it again as PNG and as JPEG. After either save, 0 of the 9 read a record, and all 18 outputs read "No supported provenance signals found". It was one browser and one JPEG quality, and a canvas is not a platform. A missing record means it is gone from that copy; it says nothing about where the picture started.
What this means when you check an image
Open the checker, choose the file, and look for the headline "Content Credentials found; legacy trust-list match". The line under it begins "Signed by Microsoft Corporation" and says the signer is on the Interim Trust List (frozen January 1, 2026), not the current C2PA Trust List. In the findings the record is labelled "Verified on the Interim Trust List".
It tells you a signed record is present, that the signature holds, that the image matches it, and that the signer is on the older list only. It does not tell you the record's claims are true, or what happened to the file after it was exported. A different headline, such as "No supported provenance signals found", does not mean a person or another tool made the image. The checker's limits line applies: "These checks cannot determine whether an image is AI-generated."
To look at the record in another viewer, Microsoft's Azure documentation points to a Verify page that now redirects to the Content Authenticity Initiative's Verify site. It opens another company's site, you may need to sign in, and your image is uploaded to them, not to us.
Guides on this topic
- How to tell if an image is AI is the main page on this topic.
- The C2PA Trust List and the Interim Trust List shows who is on which list.
- Adobe Firefly and the legacy trust-list match covers the other signer that reads this way.
- Which AI image generators add watermarks? compares what each maker says it adds.
- What "signer not trusted" means explains the result for signers on neither list.
Frequently asked questions
- Does Bing Image Creator add Content Credentials?
- Microsoft's Bing Image Creator feature page says it has implemented content credentials based on C2PA. The two Image Creator files we hold each carry a record whose certificate names Microsoft Corporation. Those files came to us through third-party uploads, so they show what our checker reads, not what Microsoft does every time.
- Does "legacy trust-list match" mean the record is bad?
- No. It means the signature and the image match hold, and the signer is on the frozen Interim Trust List but not on the current C2PA Trust List as we loaded it. It does not show the claims are true.
- Does a missing record mean the image did not come from Microsoft?
- No. Our own test found no record in any of the nine files after we redrew them through a browser canvas and saved them again. A missing record leaves the question open.