How to strip every id3 field from a podcast mp3 before it goes live
- Step 1Open the ID3 Ghoster on a Pro plan — The Ghoster is a Pro-tier security tool — the Free tier is blocked and throws "requires the pro plan." Pro allows files up to 100 MB; Pro-media raises it to 500 MB and Developer to 2 GB. A normal 30-60 minute episode (20-80 MB) fits inside Pro.
- Step 2Drop your exported episode MP3 — Drag the episode onto the dropzone labelled "Drop one or more files." The dropzone accepts multiple files, but each run strips the first file only — drop one episode at a time. The tool expects an
.mp3(MPEG audio) export. - Step 3Run the strip — There are no options. Click run. The tool reads the
ID3magic and synchsafe size at the front, then scans the tail forAPETAGEX(APEv2),TAG(ID3v1), andLYRICS200(Lyrics3v2), computing the exactstartandendof the audio. - Step 4Let it slice out the audio — Every recognized tag region — the leading ID3v2 block with its feed URL, notes, and art, plus any trailing tags — is excluded, and the audio bytes between
startandendare returned as a newaudio/mpegblob. The audio stream is never touched. - Step 5Download the anonymized episode — The output is named
<episode>-tagless.mp3(the.mp3extension is replaced). The metrics panel shows input vs output bytes; the difference is the metadata weight removed, usually dominated by the cover art. - Step 6Confirm before you publish — Open the cleaned file in any tag viewer — every field should be empty and no feed URL should remain. For a byte-level check, run it through hex-header-inspector and confirm the first bytes are an MPEG frame sync (
FF Fx), not theID3magic. Then upload to your host, which re-tags with the official metadata.
Podcast ID3 fields that leak — and whether the Ghoster clears them
These are the frames a podcast editor commonly writes. Every one lives inside the ID3v2 block, which the Ghoster removes whole; the audio frames themselves are copied unchanged.
| Field / frame | What it leaks | Where it lives | Cleared by Ghoster? |
|---|---|---|---|
WFED (podcast feed URL) | Your private staging or internal feed endpoint | ID3v2 block, file start | Yes — whole block removed |
COMM (comments) | Production notes: "DRAFT", "send to sponsor", episode brief | ID3v2 block, file start | Yes |
TENC / TSSE (encoder) | Your editing software / machine (LAME, iTunes, Audition) | ID3v2 block, file start | Yes |
APIC (embedded cover art) | Working art, sometimes an unreleased cover | ID3v2 block, file start | Yes — typically most of the removed bytes |
TIT2 / TPE1 / TRCK (title/artist/track) | Working episode title and numbering | ID3v2 block, file start | Yes |
| Legacy ID3v1 (title/artist/year) | Stale duplicate metadata from older tools | Last 128 bytes, file end | Yes — last 128 bytes trimmed |
Where it runs, limits, and output
The Ghoster is browser-first with a server-safe path. File limits follow the security family per subscription tier; the tool's own gate is the Pro minimum.
| Property | Value | Notes |
|---|---|---|
| Minimum plan | Pro | Free tier throws "Audio ID3 Ghoster requires the pro plan" |
| File-size limit (Pro / Pro-media / Developer) | 100 MB / 500 MB / 2 GB | A long episode is usually 20-80 MB — inside Pro |
| Batch slots (Pro / Pro-media / Developer) | 5 / 50 / unlimited | Dropzone accepts multiple, but each run strips the first file |
| Input format | MP3 (MPEG audio) | Output mime audio/mpeg; non-MP3 input is sliced by the same markers and may not be valid |
| Output (browser) | Downloadable blob, audio/mpeg | Filename <episode>-tagless.mp3; metrics show inputBytes / outputBytes / durationMs |
| Output (server-safe path) | JSON with outputBase64, inputBytes, outputBytes, removedBytes, mime | Decode outputBase64 to recover the cleaned episode |
Cookbook
Real episode tag layouts and what the Ghoster does to each. Byte offsets are illustrative; the tool computes them from the actual markers in your file.
Episode pointing at a private staging feed
Your editor wrote the staging feed URL into a WFED frame so you could test playback. That URL must not ship in the public release. The Ghoster removes the entire leading ID3v2 block, so the staging endpoint never leaves your machine.
Before (file head):
ID3 04 00 00 [synchsafe size = 268000]
TIT2 "Ep 112 - working title"
WFED "https://staging.feeds.internal/show.xml"
COMM "DRAFT - sponsor read at 04:10"
APIC <240 KB cover.jpg>
...268010 bytes of tag...
FF FB ... <- first MPEG audio frame
After (-tagless.mp3 head):
FF FB ... <- file opens on the first audio frame
The WFED staging URL and all notes are gone.Guest export that carries your machine fingerprint
You bounce a rough cut to send a guest for approval. The ID3v2 TENC frame names your editor (Adobe Audition) and a COMM frame has internal notes. The Ghoster strips the leading block; the guest receives clean audio with no workflow detail.
Before:
[ID3v2: TENC "Adobe Audition 2026",
COMM "v3 - cut cold open, fix levels 22:30"]
... MPEG audio frames ...
After (-tagless.mp3):
... MPEG audio frames ... <- nothing before, nothing after
inputBytes: 44,302,118
outputBytes: 44,055,940 (ID3v2 block incl. notes + art)Trailer with both ID3v2 and a legacy ID3v1 tag
A trailer exported by an older tool has ID3v2 at the front and a 128-byte ID3v1 tag at the end, both holding stale working titles. The Ghoster clears the front block and trims the last 128 bytes.
Before: [ID3v2: TIT2 "Season 4 trailer DRAFT"] ... MPEG audio frames ... TAG S4 Trailer The Studio Hour 2026 (128 bytes) After (-tagless.mp3): ... MPEG audio frames ... <- both ends clean
Pre-publish QA: confirm no URL survives
Before upload, verify the strip worked. Compare bytes in the metrics panel, then inspect the head. The cleaned file must start on a frame sync, not the ID3 magic.
Step 1 - metrics panel: inputBytes 48,210,440 outputBytes 47,948,286 -> ~256 KB metadata removed Step 2 - hex-header-inspector on -tagless.mp3: offset 0: FF FB 90 64 ... <- MPEG frame sync, good (NOT 49 44 33 = "ID3") Upload to host -> host re-tags with official metadata.
Automated publish step via the server-safe path
Your publish script sends each finished episode to the JAD runner before it hits the CDN. The response carries the cleaned bytes as base64 plus byte counts, so the pipeline can log how much metadata it stripped per episode.
POST episode-112.mp3 to the runner ->
response JSON:
{
"outputBase64": "//uQ...",
"inputBytes": 48210440,
"outputBytes": 47948286,
"removedBytes": 262154,
"mime": "audio/mpeg"
}
decode outputBase64 -> push episode-112-tagless.mp3 to CDNEdge cases and what actually happens
No episode dropped before running
Error: no fileThe audio-id3-ghoster path requires a file and throws "No file provided." with an empty dropzone. Drop the episode MP3 first, then run.
Free-tier account tries to run it
Rejected: plan requiredThe Ghoster's minimum tier is Pro. On Free the processor throws "Audio ID3 Ghoster requires the pro plan." Upgrade to Pro or higher. This gate is independent of file size.
Very long episode over the tier limit
Rejected: too largeSecurity-family limits are 100 MB on Pro, 500 MB on Pro-media, 2 GB on Developer. A multi-hour lossless-quality export could exceed Pro; move to Pro-media/Developer or export at podcast bitrate (64-128 kbps) first.
Episode already stripped by your host's re-tag
By designIf a file has no ID3 magic and no trailing TAG / APETAGEX / LYRICS200 markers, nothing matches and the file is returned essentially unchanged. Running an already-clean episode is safe — the tool never removes audio it cannot identify as a tag.
Cover art dominates the removed bytes
ExpectedEmbedded art lives in the ID3v2 APIC frame, often 100-500 KB, so it is usually the bulk of the removed bytes. The strip is all-or-nothing per region — there is no option to keep the art and drop only the feed URL. Your host re-adds the official art on ingest.
You drop several episodes at once
First file onlyThe dropzone accepts multiple files (Pro allows 5 slots), but each run strips the first file and emits one -tagless.mp3. Drop-run-download per episode, or script the server-safe path for a real publish pipeline.
Chapter markers stored in the ID3v2 tag
Removed with the tagPodcast chapter markers written as ID3v2 CHAP/CTOC frames are part of the leading block and are removed with everything else. If your host generates chapters from its own UI, re-add them there after upload; the Ghoster's job is full anonymization, not selective edits.
Non-MP3 export (WAV, FLAC, M4A) dropped
Wrong toolThe Ghoster targets MP3 ID3/APE/Lyrics3 structures. A WAV, FLAC, or M4A/AAC export does not use these, so the marker scan finds little and the output is not a cleaned version of that format. For MP4-container audio, metadata lives in atoms — use the video metadata scrubber at /video-tools/metadata-scrubber.
ID3v2 footer present (rare)
ExpectedThe tool computes the leading tag size from the synchsafe size at bytes 6-9 only. The rarely-used ID3v2 footer flag adds an extra 10 bytes that this size does not include, so a handful of bytes from a true footer could remain at the front. This is harmless to playback and uncommon in podcast exports; the audio stream is untouched.
Truncated export where the synchsafe size overruns the file
ExpectedIf a damaged export has an ID3v2 size pointing past the end of the file, the computed audio start lands at or beyond the real end, yielding a tiny or empty output. That signals a broken source — re-export the episode and run again.
Frequently asked questions
Will this remove the staging feed URL from my episode?
Yes. A podcast feed URL is stored in an ID3v2 WFED frame inside the leading tag block, which the Ghoster removes whole. Any private staging or internal feed endpoint goes with it. There is no way to leave it behind because the strip clears the entire block in one pass.
Does stripping tags change how my episode sounds?
No. The tool does not re-encode. It computes where the metadata ends and the audio begins, then returns the MPEG frames unchanged with buf.slice(start, end). Loudness, bitrate, sample rate, and the audio stream are bit-identical to your master export.
Should I strip before or after uploading to my host?
Strip before you hand the file to anyone outside your host — guests, sponsors, download mirrors. Most hosting platforms re-tag the episode with official metadata on ingest, so the public version is theirs; the Ghoster protects the copies you distribute directly.
Are there options to keep the title but drop the URL?
No. The Ghoster has zero options — it is a single-click full strip. There is intentionally no "keep title" or "keep art" toggle, because selective keeping is exactly how a private field gets left behind. If you need specific tags afterward, your host's UI re-adds them.
Does my episode get uploaded to a server?
In the browser, no — the strip runs in-page with Web APIs and the bytes never leave your device. There is also a server-safe path (used by the JAD runner) that returns the cleaned file as base64 in outputBase64 for automated publish pipelines. The default web experience is fully in-browser.
Why is my cleaned episode smaller?
Almost always the embedded cover art. Art lives in the ID3v2 APIC frame and is often 100-500 KB; removing the ID3v2 block removes the art too. The audio loses no bytes — the difference shown in the metrics panel is metadata weight, mostly art.
What happens to chapter markers?
ID3v2 chapter frames (CHAP/CTOC) are part of the leading tag block and are removed along with everything else. If your host generates chapters in its own interface, re-add them after upload. The Ghoster performs full anonymization, not selective metadata edits.
What plan do I need?
Pro or higher. The Free tier is blocked and throws "requires the pro plan." File limits then follow the security family: 100 MB on Pro, 500 MB on Pro-media, 2 GB on Developer. A typical episode is 20-80 MB, well inside Pro.
Can I strip a whole season at once?
The dropzone accepts multiple files (Pro allows 5 batch slots), but each run strips the first file and produces one -tagless.mp3. For interactive use, drop-run-download per episode. For a real season pipeline, use the server-safe path via the JAD runner and loop over your files.
How do I prove the episode is clean before publishing?
Compare input vs output bytes in the metrics panel, open the file in a tag viewer to confirm every field is empty, and run it through hex-header-inspector — the first bytes should be an MPEG frame sync (FF Fx), not the ID3 magic. You can also hash before/after with multi-hash-fingerprinter.
What about M4A or AAC episodes?
Those use MP4-container atoms, not ID3/APE/Lyrics3 structures, so the Ghoster is the wrong tool. For MP4-container audio and video metadata, use the video metadata scrubber at /video-tools/metadata-scrubber.
Which other JAD security tools help with publishing privacy?
To strip author and comments from show notes documents, use office-doc-property-wiper. To pull embedded preview images out of any file, use hidden-thumbnail-extractor. To confirm a file's true type and inspect its byte structure, use magic-byte-validator and hex-header-inspector.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.