How to embed copyright and contact details in your photos

Most advice about photo metadata tells you to delete it. That advice is usually right: your camera writes GPS coordinates, timestamps and a serial number into every file, and posting a photo taken at home hands out your address. We wrote that post, and it stands. This one is the deliberate opposite, and both can be true at once, because metadata is not one thing.

There is a private half and a public half. The private half is where and when you were, and which body took the shot. The public half is who made the picture, who to contact about it, and what the licence is. The best workflow strips the first and keeps the second.

Here is how to write the second half properly, where it survives, and, importantly, what it will not do for you.

Why this is the exact opposite of the privacy post, and why that is fine

If you have read what EXIF data is and why it matters for privacy, you already know a photo file carries a header full of fields the viewer never shows you. That post is about the fields you did not choose and would rather not publish.

The rights fields are the ones you write on purpose. Nobody's camera fills in "contact me at this email for licensing". You do, or nobody does.

Treat them as two separate decisions. Location and personal identifiers: remove before publishing. Creator, credit and copyright: add before publishing. The tooling makes it easy to get this backwards, because plenty of "clean your metadata" buttons remove everything indiscriminately, including the fields you spent time writing.

Three metadata systems, and the one you should actually use

Photos can carry rights information in three different places, and they overlap.

Exif is the camera's own block. It has exactly two relevant fields, Artist and Copyright. Some cameras let you type these into the menu once so every file gets them automatically. It is crude, but it is also the most widely readable of the three, and it costs you nothing.

IPTC IIM is the older news-industry standard from the early 1990s. It is where "byline", "credit" and "copyright notice" as concepts come from. Plenty of picture desks and stock systems still read it, so tools generally keep writing it alongside the modern version.

XMP is Adobe's XML-based container and the one the current IPTC Photo Metadata Standard is built on. It holds far more structure than the other two, including proper contact details and a machine-readable licence URL. This is the one to fill in. Any decent tool writes XMP and mirrors the key values back into the IPTC and Exif fields for compatibility, so you fill in one panel and get all three.

The fields worth filling in

You do not need all of them. These are the ones that do real work:

The contact field is the one people skip and the one that matters most. A copyright notice tells someone they cannot use the image. A contact address tells them how they can, which is the outcome you probably want.

How to write the fields

You need software that writes metadata. Every option below does it without re-encoding your pixels, so the image itself is untouched.

• Lightroom Classic: the Metadata panel in the Library module. Fill it in once, save it as a metadata preset, and apply it to every import.
• Adobe Bridge: free with a Creative Cloud account. Select any number of files, use the Metadata panel or File Info, and apply a metadata template to the whole selection at once.
• ExifTool: free, command line, and the most complete implementation there is. It is the reference tool other software gets checked against.
• Photo Mechanic: paid, and the standard in sports and news precisely because it applies metadata templates at ingest speed.
• darktable, digiKam, XnView: free desktop options with proper IPTC and XMP editors.
• The operating system: Windows File Explorer's Properties tab and the macOS Photos info panel can set a few fields. Enough for one file, painful for a hundred, and they do not cover the full IPTC set.

An ExifTool example, since it is the one people ask for. This writes the core fields across XMP, IPTC and Exif in one pass and leaves the original file in place rather than making a backup copy:

exiftool -overwrite_original \
  -XMP-dc:Creator="Your Name" \
  -XMP-dc:Rights="© 2026 Your Name. All rights reserved." \
  -XMP-plus:Licensor="Your Name" \
  -XMP-xmpRights:WebStatement="https://example.com/licensing" \
  -XMP-xmpRights:UsageTerms="Contact for licensing" \
  -XMP-iptcCore:CreatorWorkEmail="you@example.com" \
  -XMP-iptcCore:CreatorWorkURL="https://example.com" \
  -IPTC:By-line="Your Name" \
  -IPTC:CopyrightNotice="© 2026 Your Name" \
  -EXIF:Artist="Your Name" \
  -EXIF:Copyright="© 2026 Your Name" \
  photo.jpg

Drop the -overwrite_original flag while you are experimenting and ExifTool will keep the untouched file alongside the new one. Point the command at a folder instead of a filename and it processes everything inside.

What survives an upload, and what does not

This is where expectations need adjusting. Embedded metadata travels with the file itself, so it survives copying, emailing, moving between drives, and most format conversions handled by software that bothers to carry it across.

What it frequently does not survive is a platform that re-encodes your image. Large social platforms resize and recompress everything you upload, and the copy they serve to the public is generated from your pixels, not from your file. Metadata is not automatically part of that copy.

Behaviour varies a lot, and it changes without announcement:

• The big social platforms generally strip most or all metadata from the public copy. Some deliberately preserve the IPTC rights fields while dropping everything else. Some drop those too.
• Photo-sharing and portfolio sites aimed at photographers, along with most stock libraries, usually preserve the full IPTC set, because their users would revolt otherwise.
• Content management systems are inconsistent. The original upload usually keeps its metadata, while automatically generated thumbnails and resized versions often do not, because the image library doing the resizing drops it by default.
• Messaging apps almost always strip, since they aggressively recompress to save bandwidth.

Rather than trusting any list, including this one, test it. The IPTC publishes a Social Media Sites Photo Metadata Test that tracks which platforms retain which fields and updates it as behaviour changes. And you can check any individual file yourself: download your own image back from wherever you posted it and drop it into our image metadata viewer to see what actually made it through. The viewer reads the file in your browser and shows you what is in the header, which is the only reliable way to know.

One thing worth being clear about: our metadata tool reads, it does not write. Use it to verify, and use ExifTool, Lightroom or Bridge to author the fields in the first place.

This is not DRM, and pretending otherwise will cost you

Embedded metadata provides no protection whatsoever. None. It is a text field in a header.

Removing it takes one command, or one "export for web" checkbox, or one pass through any tool that re-encodes an image from pixels, which quietly discards the header as a side effect. A screenshot removes it. Anyone who wants your photo without your name on it will have it without your name on it, in seconds, without needing to know anything technical.

So if your goal is to stop theft, embedded metadata does not do that, and neither does anything else that lives inside the file. Visible watermarking is the only in-file measure that survives a screenshot, and it costs you the look of the image. Low-resolution previews limit what a stolen copy is good for. Those are the actual levers.

There is a legal wrinkle worth knowing rather than relying on. In the United States, the DMCA has a provision covering copyright management information, and knowingly stripping it to conceal infringement can carry consequences of its own, separate from the infringement. Whether that helps in any specific situation is a question for a lawyer, and formal registration is what determines the remedies actually available to you in the US. Metadata is supporting evidence, not a substitute.

What it is genuinely good for

Set the expectation correctly and embedded rights data earns its keep every week. It also only makes sense once you have decided what terms you are offering in the first place, which is what our guide to image licensing is for.

It makes crediting you the path of least resistance. A blog editor with your photo open in Bridge sees your name and your licensing URL right there. Most people who use images without credit are not thieves, they are people who could not find out who made it. You are removing the excuse.

It survives the handoff chain. A file passed from a client to their agency to a printer keeps your details attached at every step, long after the email thread with your name on it has been forgotten.

It turns a found image into an enquiry. This is the whole return on the contact field. Someone finds your photo, wants to use it properly, and can.

It is your own filing system. Consistent creator, description and title fields mean your catalogue is searchable in ten years, by you, in whatever software you are using then.

It supports a claim without being the claim. When you do find an unauthorised use, an original file with intact metadata, alongside the RAW and the original timestamps, is part of a coherent story about provenance.

Content Credentials, and where this is heading

The obvious weakness in all of the above is that anyone can type anything into a metadata field. There is no signature and nothing to verify.

C2PA, the standard behind Adobe's Content Credentials, addresses that with cryptographically signed provenance: who captured or created an image, what was done to it afterwards, and whether the record has been tampered with since. Camera manufacturers and editing software have begun shipping support, and it is being pushed hard as a response to AI-generated imagery.

It is early. Support is patchy, most platforms do not display the credentials, and the same basic vulnerability applies in that stripping the data still removes it, though the difference is that the removal becomes detectable rather than silent. Worth turning on if your software offers it. Not worth restructuring your workflow around yet.

The workflow, start to finish

Putting it together for a set of photos you are about to publish:

1. Set your camera's in-menu copyright field once, so every capture starts with a name attached.
2. Build one metadata preset in whatever cataloguing software you use, containing creator, contact, copyright notice, usage terms and your rights URL. Apply it on import so it is never a separate task.
3. Update the year in your notice each January. It is the single most common thing people get wrong, and a notice reading 2019 on a photo taken last week undermines the whole exercise.
4. On export, remove location data. Most editors have an explicit "remove location info" option that leaves the rights fields alone. If yours does not, run exiftool -gps:all= file.jpg before publishing.
5. Verify the exported file before it goes anywhere. Confirm the rights fields are present and the GPS block is gone.
6. Accept that platforms will do what they do. Keep your master file, with everything intact, somewhere you control.

Steps four and five are where the two halves of this topic meet. You are not choosing between privacy and attribution. You are stripping one set of fields and keeping another, in that order, every time.