Rinse · Remove Content Credentials
Where the manifest actually lives, the exiftool commands that read it and take it out, what we tested ourselves, and an honest account of what removal does not do.
Commands verified on macOS with exiftool 13.55, 2026-09-04.
The short answer
Content Credentials are metadata. They sit in a container box inside your file, not in the pixels, so they can be read out and taken out like any other metadata.
# see whether the file carries one
exiftool -G1 -s -a -JUMBF:all photo.jpg
# remove it, along with the rest of the writable metadata
exiftool -all= photo.jpg
# prove it is gone. this step is not optional
exiftool -G1 -s -a -JUMBF:all photo.jpgThat is the whole mechanic. If you came here for the command, take it, it is free and exiftool is the right tool. The rest of this page is what stops you getting burned: what the credential actually is, which of your tools wrote it, the ways removal quietly fails, and what removal cannot achieve no matter what any product tells you.
If you landed here because a platform put an AI label on your work, start with Instagram put an AI label on your real photo or the cross-platform version, why your photo says "Made with AI". This page is the technical one.
What you are removing
"Content Credentials" is the consumer name. The standard underneath is C2PA, from the Coalition for Content Provenance and Authenticity, and what it produces is a manifest: a cryptographically signed record saying what made this file, what was done to it, and by which application.
The manifest is packed in a JUMBF box, a generic container format borrowed from JPEG 2000. Where that box is embedded depends on the file:
APP11 marker segment, byte marker
0xFFEB, sitting near the top of the file. This is the common case
and the one this page is strongest on.
caBX chunk in the chunk stream.
Two consequences follow, and they are why a lot of advice on this topic is wrong. First, a Content Credential is not an EXIF tag. A tool that only knows how to clear EXIF can leave the manifest completely untouched and still report success. Second, because it is signed, editing it is not a thing you can do. You either carry the manifest or you do not.
The manifest rarely arrives alone. The same export usually carries an XMP packet with
edit history and CreatorTool, an EXIF Software tag, and
sometimes DigitalSourceType, an IPTC Extension field that AI tools set to
a value ending in trainedAlgorithmicMedia. If you want your file to stop
announcing how it was made, that last one is at least as explicit as the manifest is.
Who put it there
Almost nobody adds a Content Credential deliberately. It arrives as a by-product of normal work.
Source: eyesift.com, C2PA adoption overview (2026).
Because platforms read it. Meta generates Instagram's AI labels from provenance metadata in the uploaded file, C2PA Content Credentials included alongside IPTC and XMP, and has labelled real photographs that way. The most cited case is a basketball photograph by Pete Souza, the former White House photographer, and Meta's Oversight Board has issued a finding on the labelling approach. TikTok uses Content Credentials to detect and label synthetic media automatically, whether or not the creator declared anything, and YouTube applies labels to video it detects as AI-generated.
Sources: fstoppers.com, "Instagram's ham-fisted approach labeling photos AI" (2025); storrito.com, "TikTok's 2026 AI labeling rules" (2026).
There is a second reason that has nothing to do with AI. A manifest is a record of your process, and a studio delivering to a client does not necessarily want the software chain, the edit history and the equipment list travelling with the file. Same removal job, different hat.
Worth saying plainly: C2PA exists for a good reason, and a signed provenance chain is a genuinely useful thing for journalism and evidence. Stripping it from your own work so it stops being mislabelled is a different act from stripping it to pass something off as something it is not. We are not going to pretend the second one is impossible, and we are not going to help you frame it as the first.
Step one
Free, thirty seconds, and it decides whether the rest of this page applies to you.
The tool is exiftool, by Phil Harvey: free, open source, and what a lot
of metadata utilities run underneath, ExifCleaner and Rinse included.
# install it (Homebrew), or get the package from exiftool.org
brew install exiftoolexiftool -G1 -s -a -JUMBF:all photo.jpg
A file carrying Content Credentials answers with a [JUMBF] group. You
will typically see a JUMDLabel of c2pa and a
JUMDType beginning (c2pa), followed by whatever the
manifest declares. A file with nothing prints nothing, and that is your answer.
exiftool -G1 -s -a -JUMBF:all -XMP:all -IPTC:all \
-EXIF:Software -DigitalSourceType photo.jpgThis is the command worth keeping. It shows the manifest, the XMP edit history, the IPTC block, the application name and the AI source-type declaration together, which is the full picture of what your file says about itself.
exiftool -r -q -p '$Directory/$FileName' -if '$jumbf:all' \
-ext jpg -ext jpeg -ext png -ext heic ./export
Walks ./export and prints only the paths of files with a JUMBF box in
them. Verified working on exiftool 13.55. Useful before a delivery goes out, when
you want the list rather than a wall of tag output.
Inspect the export, not the master. The file that matters is the one that actually leaves your machine: the JPEG you upload, the HEIC that syncs to your phone, the folder you hand a client. Your catalogue tells you nothing about what is inside the file at the end of the chain.
Step two, the free way
One command removes every writable tag exiftool can name, the JUMBF box included:
exiftool -all= photo.jpg
We checked that this genuinely removes the box, rather than assuming it.
On 2026-09-04 we built a JPEG carrying a valid C2PA-shaped JUMBF box in an
APP11 segment, confirmed exiftool 13.55 parsed it as Content Credentials,
ran exiftool -all= over a copy, then scanned the raw bytes of the output
rather than just re-querying the tags. Zero occurrences of the 0xFFEB
marker, the jumb box, the c2pa type or the manifest
identifier. Gone at the byte level. The honest limit: our fixture was a manifest we
constructed, not a real signed one from Photoshop, so what was proven is the container
surgery. Which is why the verification step below exists.
The removal has sharp edges, and each of these has caught someone out.
-all= means all: your copyright notice, your byline, and your EXIF
orientation flag, and a stripped orientation flag can leave a phone photo displaying
on its side. Name what should survive:
exiftool -all= -tagsfromfile @ -Orientation -IPTC:CopyrightNotice \
-overwrite_original photo.jpg
-tagsfromfile @ means "read those tags back from this same file", so
they are restored after the wipe. Verified: the JUMBF box does not come back with
them.
By default exiftool writes in place and leaves the untouched original beside it as
photo.jpg_original. Add -overwrite_original, as above, and
that safety net is gone. Copy your files somewhere else first, and never let a batch
run be the only version you own.
This is the step everyone skips, and it is the one that matters. Run the inspection
command again on the output and confirm the [JUMBF] group has actually
disappeared. Metadata removal has quiet failure modes: a container the tool does not
fully parse, a format variant it declines to write, or an encoder that puts a fresh
tag straight back in. Reading the file afterwards is the only proof that counts, and
it costs you one line.
Comfortable in a terminal? Stop here. exiftool is free, it is genuinely the right tool, and ExifCleaner is a free graphical option. The rest of this page is for people who do not want to do this by hand before every delivery.
Step two, the $9 way
Rinse is a small Mac utility that does the above to every image you drop into a
folder. A Clean folder sits on your Desktop. Drag in one file or a whole export.
Cleaned copies appear in the Cleaned folder beside it, usually in about two seconds,
and your untouched originals are kept in ~/Rinse/originals/ with a
timestamp on each one.
Rinse's first pass decodes the pixels and writes a fresh container.
An APP11 segment survives that only if the encoder deliberately
regenerates it, and macOS ImageIO does not regenerate JUMBF. So the removal is
structural rather than a blocklist of markers it has been taught to recognise, which
is also why it holds for manifest versions that did not exist when the code was
written. A second pass runs exiftool over the result.
Verified for JPEG on 2026-09-04, by the same test described above,
run against the exact shipping pipeline: the JUMBF box was gone after pass one alone,
confirmed by raw byte scan. We wrote that test before this page existed, because a
claim we have only asserted is not a claim we are willing to print.
PNG we have not tested. PNG carries C2PA in a caBX
chunk and the same fresh-container logic should apply, but it has not been proven, so
we are not claiming it. If that is your case, run the inspection command on the output
and see for yourself.
It shows you what it found. Rinse counts the metadata fields in your original before it cleans, then tells you what it removed ("photo.jpg • 7 tags removed"), records it in its log, and flags any privacy or AI field that survived the pass. That receipt is the point. You are not asked to take the removal on trust, and you can check it with the exiftool command above whenever you like.
Or read the full product page first.
Rinse re-encodes the pixels into a fresh container as its first pass, at quality 0.92. In normal use the result is visually identical to the original, same dimensions, same colour, and your original is always kept. It is not a byte-for-byte copy of the pixels, and we do not claim it is. If bit-exact pixels matter to you, exiftool leaves them completely untouched, so use exiftool.
Rinse is also not code-signed yet. Our Apple Developer enrolment was submitted in September 2026 and is being verified as of writing, so on macOS 15 Sequoia and later the first launch means dismissing a warning, then clicking "Open Anyway" in System Settings under Privacy & Security. Once, then never again. We would rather tell you now than at the moment you have just paid.
Where this stops
Removing a Content Credential removes a Content Credential. It is a smaller act than the marketing around this subject usually implies.
A manifest is a copy of a record, not the record itself. Cleaning your local file has no effect on what a platform, a service, or anyone you already sent the file to has stored on their own systems. Nothing you run on your Mac reaches a file that is already somewhere else.
Platforms increasingly pair metadata reading with their own classifier-based detection, TikTok and Pinterest among them. Removing the manifest removes the metadata trigger. It does nothing about a model looking at your image and forming a view. Whatever a platform's classifier decides is beyond the reach of any metadata tool, Rinse included, and nobody can promise you a label will not appear.
Google's SynthID and similar pixel-domain watermarks are woven into the image itself, not into its metadata. Rinse does not remove SynthID and cannot. Neither can exiftool, or any other metadata tool. Only diffusion-based regeneration can weaken a watermark like that, and even then never with certainty. If a page tells you otherwise, you can check it in five minutes and find out it is false.
Rinse is not built for that and does not achieve it. It exists because photographers, agencies and studios keep getting real work flagged over fields that Adobe, a camera, or a retouching step wrote without asking. That is the problem it solves, and where it stops is written on the box.
Related questions
A Content Credential is a signed C2PA manifest embedded in a media file: a record
of what created the file, what edited it, and with which application. It is
carried in a JUMBF container box, in an APP11 segment in JPEG, a
caBX chunk in PNG, or an ISO base media box in HEIC and AVIF. Adobe
applications write them, a growing list of cameras write them, and AI generators
such as OpenAI's attach them to their output.
On a Mac, exiftool -all= photo.jpg removes the JUMBF box along with
the rest of the writable metadata, and exiftool -G1 -s -a -JUMBF:all
photo.jpg before and after tells you whether it worked. Both commands are
free. Verify the output rather than trusting the run: metadata removal fails
quietly more often than it fails loudly.
It removes it. We tested this on 2026-09-04 with exiftool 13.55: a JPEG carrying a
valid C2PA-shaped JUMBF box in an APP11 segment, run through
exiftool -all=, then scanned at the byte level rather than re-queried.
The 0xFFEB marker, the jumb box and the manifest
identifier were all absent from the output file. The fixture was a manifest we
constructed rather than one Photoshop wrote, so treat it as proof about the
container surgery, and check your own files.
The same way as any other Content Credential: they are C2PA manifests in a JUMBF
box, and the commands on this page apply to a Lightroom or Photoshop export
exactly as they do to anything else. Do it on the exported file, not the
catalogue. Also look at what else Adobe wrote alongside it, particularly the XMP
edit history and CreatorTool, which frequently say more about your
process than the manifest does.
It removes the metadata trigger, which is the documented mechanism behind those labels. It cannot cover a platform's own pixel classifier, and platforms increasingly run both. It also does nothing to a post that is already live, since that is a separate copy of the file on someone else's servers. We will not tell you it is guaranteed, because it is not ours to guarantee.
No. The manifest is cryptographically signed, so altering its contents invalidates it rather than changing what it says. In practice the choice is binary: the file carries the credential or it does not.
Yes, and for JPEG we have verified it rather than asserted it, by test on
2026-09-04 against the shipping build. Rinse's first pass writes a fresh
container, which the JUMBF box does not survive, and the app then reports how many
fields it removed so you have a receipt. PNG C2PA lives in a caBX
chunk and we have not tested that case, so we do not claim it. Rinse handles
images only: JPEG, PNG, TIFF, HEIC, AVIF and static GIF.
For most technical users, exiftool is enough. It is free, it is excellent, and the commands are on this page. ExifCleaner is a free graphical alternative. Rinse is $9 for a folder that cleans by itself, bundled binaries so there is nothing to install, and a count of what it removed. If you already have exiftool aliased in your shell, you probably do not need Rinse, and we would rather say that than pretend otherwise.
$9. One Mac. Local only. 7-day refund, no questions.
JPEG, PNG, TIFF, HEIC, AVIF and static GIF.