Explicit Flag
Damian Moore, Last updated: 15 October 2026
Checks that episodes containing swearing are marked explicit in your feed, so Apple Podcasts and Spotify show the right content advisory.
Most podcast directories let listeners filter out explicit shows, and they rely on you to say which episodes are explicit. You do that with the itunes:explicit tag in your feed, normally set by a tick box in your hosting platform. Apple’s content guidelines ask creators to flag any episode with profanity or content that may not be suitable for children; our guide to ensuring your podcast is family friendly quotes them and covers what an explicit label means for your audience.
The Explicit flag check looks for one specific mismatch: swearing in an episode that your feed doesn’t mark as explicit. It’s Required in every built-in standard, so of all the checks it’s the one most likely to fail a report outright.
When it fails and when it passes
- Fails when the episode contains swearing and isn’t marked explicit in your feed.
- Passes when the episode contains swearing and is marked explicit. That’s the flag doing its job.
- Passes when there’s no swearing at all, whatever the flag says.
- A missing
itunes:explicittag counts as not explicit, the same way podcast apps read it. So the check applies to every feed episode, not just ones that carry the tag.
It’s not applicable, and no row is shown, for uploads (there’s no feed to read a flag from) or for feed episodes whose flag we haven’t determined yet. Either way it doesn’t count towards the report’s total.
Only confident swearing counts
Swearing is found in the transcript, using the same list of words as the Profanities check, matched on whole words regardless of capitals. Mild words such as “damn” and “hell” aren’t on the list, and censored transcriptions such as “f**k” still count.
Transcription sometimes mishears an ordinary word as a swear word, so only swearing heard with 75% confidence or more can fail this check. Hits below that still appear in the Profanities check, marked “Low confidence — didn’t fail the explicit flag”, and when the explicit flag check passes it says how many low-confidence hits it ignored. Every hit is timestamped, so you can click through and listen. Each one is also tagged in the transcript, which helps you hear it in context.
The flag is re-read from your feed
Each time Audio Audit polls your feed, it re-reads the newest episode’s itunes:explicit value, for as long as that episode is the newest item in the feed. If you mark a failing episode explicit at your host (Megaphone, Buzzsprout and so on) before your next episode goes out, the report turns green on its own after the next poll: no retry, no extra credits. Once a newer episode is published, the older one’s flag is no longer refreshed.
An email or webhook already sent for the report isn’t sent again, but reopening the report always shows the current verdict.
How to fix it
You have two choices:
- Mark the episode explicit in your hosting platform. If the swearing is meant to be there, this is the quickest fix, and the report updates on the next poll as described above.
- Edit the swearing out. Bleep or mute each word in your editor (the Profanities timestamps tell you where), then re-upload the episode to your host. The existing report was measured on the original audio and won’t change, so upload the edited file to Audio Audit if you want to confirm the Profanities check comes back clear.
Changing it in a custom standard
In a custom standard you can set the explicit flag check to Informational, so it’s shown but never fails the report, or turn it Off. Think twice before you do: an unflagged swearing episode is exactly the kind of thing directories act on, and with the check turned down your reports will no longer fail on it. If you want to go the other way, make Profanities Required so that any swearing fails the report, flagged or not.
