ISRC vs UPC: how music identifiers prove ownership and power takedowns.

1. What is an ISRC?

An International Standard Recording Code (ISRC) is a 12-character alphanumeric identifier defined by ISO 3901. It identifies one specific sound recording or music video — the master, not the song, not the release. The 2024 master, the 2025 live cut and the 2026 remix of the same song each receive their own ISRC.

The format breaks down into four ordered parts:

• 2-letter country code — ISO 3166-1 alpha-2 of the registrant's country. US, GB, AU, DE, and so on. QM and QZ are reserved blocks used by most US-based distributors when local US codes run out.
• 3-character registrant code — uniquely identifies the entity that issued the ISRC. Major labels have their own. Most distributors share their pool with every artist they distribute, which is why you'll see the same three characters on tens of thousands of independent releases.
• 2-digit year of reference — the last two digits of the calendar year the ISRC was assigned (not necessarily the year of release).
• 5-digit designation code — a sequential per-year counter the registrant chooses. 100,000 codes per registrant per year (00000–99999).

Who issues them. The IFPI (International Federation of the Phonographic Industry) is the global ISRC authority. National agencies handle registrant-code allocation: the RIAA ISRC Manager in the United States, PPL in the United Kingdom, ARIA in Australia, GVL in Germany, and dozens of others. Once you hold a registrant code you self-assign individual ISRCs — you do not have to ask permission per release. As of 2026 a US registrant code costs $95 one-time from the RIAA; a UK code is free for PPL members.

Who registers them. In practice, three groups: major and large independent labels (their own pool), distributors (one pool shared across all their customers), and rights-aware artists who have grown out of relying on their distributor and want full control of their ISRC namespace.

2. What is a UPC (and EAN)?

A Universal Product Code (UPC) is the same numeric barcode standard used on cans of soup and physical CDs at retail — 12 digits in the North-American UPC-A variant, 13 digits in the EAN-13 variant used everywhere else. Both are governed by GS1, which sells them in blocks. In streaming, a UPC identifies the commercial release — a specific album, EP or single SKU — not the individual recordings on it.

One album with 12 tracks therefore has 1 UPC and 12 ISRCs. Re-release the same album as a deluxe edition with 4 bonus tracks and you need a new UPC (different SKU) and 4 new ISRCs for the bonus tracks — the original 12 recordings keep their ISRCs because they are bit-for-bit the same masters.

Apple / iTunes nuances. Apple's delivery spec is the strictest in the industry. Apple normalises 12-digit UPCs to 13-digit EAN-13 by left-padding a zero, so 602508123456 becomes 0602508123456 inside iTunes Producer and the iTunes Connect rights system. When you look up your release in Apple's catalog and see a leading zero you didn't put there, that's why. Apple also rejects redeliveries that reuse a UPC for a release with a materially different track list, runtime, or artist credit — a duplicate-UPC warning from your distributor almost always traces back to Apple's validator. Spotify and Amazon are more permissive but apply the same rule under the hood when you go through their direct-licensed pipelines.

Release-level vs recording-level. This is the single most important distinction in the entire identifier system. A UPC binds to a release (what someone buys or streams as a unit); an ISRC binds to a recording (what someone actually hears). DSP analytics, royalty payouts, and DMCA matching all care about ISRCs — but discovery, marketing, and pre-save links live on the UPC.

3. Why both matter for catalog protection

When a stolen, leaked or unauthorised version of one of your songs shows up on a DSP, the enforcement question is always the same: how do you prove the master uploaded by an unauthorised account is the same recording you own? There are three answers, in ascending order of legal strength.

1. Audio fingerprint match — strong technically but DSPs rarely expose fingerprint comparison to rights holders; YouTube's Content ID is the major exception.
2. ISRC match — strong legally and operationally. If the infringing upload carries your ISRC, you have a direct paper trail from registry to release.
3. UPC match — strong only when the entire release was duplicated. Useful for "white-label rip of full album" cases.

A complete enforcement workflow uses all three. Audio fingerprints catch the cases where the infringer stripped the ISRC. ISRC matches catch the cases where the infringer copied the metadata verbatim (the majority of fake-artist and stream-farming uploads). UPC matches catch the cases where the infringer redelivered the whole album through another distributor.

The reason ISRC sits at the centre is jurisdictional: it's the only identifier defined by an ISO standard with national registries. A DSP trust & safety reviewer reading your §512(c)(3) notice does not have to take your word for ownership — they can verify the ISRC against IFPI's database in seconds. UPC is verified the same way through GS1's GEPIR lookup, but only proves who registered the SKU, not who owns the underlying recording.

4. ISRC registries and how to look one up

There is no single global ISRC database that maps every code to a verifiable owner. Instead, four layers of lookup exist, each useful for different questions.

• IFPI ISRC Search — recording-level. Confirms a code exists and returns track title, artist, and the issuing registrant. Coverage is strongest for codes issued by national agencies; weaker for distributor-pool codes.
• DSP credit panels — Spotify, Apple Music, Tidal and Deezer all expose the ISRC for a streaming track via their public APIs and (sometimes) the credits panel in the consumer app. This is the easiest "does my ISRC actually appear on the live release?" check.
• Collections societies — SoundExchange (US neighbouring rights), PPL (UK), GVL (DE), SCAPR-affiliated societies elsewhere. They tie ISRC to a registered performer and rights holder for royalty distribution. This is the most authoritative ownership record short of a court filing.
• Distributor dashboards — DistroKid, TuneCore, CD Baby and similar all expose ISRCs on the release page. If your distributor assigned the code, this is your source of truth. Export the list before you ever leave a distributor — they are not required to keep it accessible to you indefinitely.

"I think one of my songs doesn't have an ISRC." If a recording is on a DSP at all it almost certainly has one — DSPs reject deliveries without an ISRC. The case where you genuinely don't have one is unreleased material: demo masters, unreleased remixes, anything that lived only on your own drives. Allocate ISRCs for those before you ever share them, even to mastering engineers, sync agents or A&R. Allocation is free if you hold a registrant code and ~$95 + per-code fees if you go through a third-party allocator.

5. Common ISRC mistakes

Five patterns produce the overwhelming majority of ISRC-related rights problems in 2026.

1. Reusing one ISRC across remixes. A radio edit, an extended mix and a club remix are three distinct recordings and need three ISRCs. Reusing one code splits streaming counts incorrectly and makes DMCA matching for any single version impossible.
2. Reusing one ISRC across masters and remasters. A 2026 remaster of a 2014 album is a new recording. Distributors sometimes auto-copy ISRCs on redelivery — verify the metadata before approving the new delivery, and assign new ISRCs to every remastered track.
3. Leaving the year-of-reference stale. The 2-digit year inside an ISRC is set when the code is allocated. If you allocate codes in bulk at the start of the year and release in December, the year matches. If you allocate in December for next year's release, the year does not match the release year — that's fine (the spec only requires it to match allocation year) but it confuses analytics tooling.
4. Not recording the ISRC alongside the master. The ISRC should live in the BWF/RIFF metadata of the WAV master and in your DAW project file, not just in the distributor delivery. When you re-deliver years later through a different distributor, your master is the source of truth — losing the ISRC mapping is how artists accidentally end up with two different codes for the same recording.
5. Trusting that a distributor will retain your ISRC if you leave. If the distributor assigned the code from their own pool, the code is theirs. When you move distributors, the new distributor will allocate a new ISRC unless you explicitly provide the old one in metadata — and the DSPs will see the same recording as two different sound recordings, splitting streams and royalties.

6. ISRC + UPC in DMCA notices — why DSPs accept them

17 U.S.C. §512(c)(3)(A)(ii) requires that a takedown notice identify "the copyrighted work claimed to have been infringed" with enough specificity that the service provider can locate it. The statute does not name ISRC or UPC, but DSPs have settled on them because they are the only widely-deployed identifiers that map cleanly to a master recording and a release SKU.

Three practical consequences flow from this:

• Spotify Content Protection has an explicit ISRC field on the takedown form. Notices that include it are routed to a fast-track queue and typically resolve in 24–72 hours; notices without it queue for manual review and can take 7–14 days.
• Apple Music's content dispute form requires UPC for release-level disputes and ISRC for recording-level disputes. They reject submissions that mix the two scopes (e.g. UPC of original release as proof for one infringing track from an unauthorised single).
• YouTube Content ID accepts ISRC as a manual-claim reference identifier — useful when a fingerprint match doesn't fire because the infringer pitched or speed-changed the audio enough to evade detection.

The deeper reason DSPs accept these identifiers as evidence is that the identifiers themselves are independently verifiable. An ISRC carries the registrant code; the registrant code is publicly attributable through IFPI; the chain from a recording to a rights holder is therefore reconstructible without the rights holder making any sworn statement beyond the §512(c)(3) good-faith declaration. That's a much easier review for trust & safety to clear than "I own this song, here's a verbal description of the audio."

7. How DSP Watch uses ISRC for hard-signal-gate matching

DSP Watch's detection engine treats ISRC as a hard signal — a deterministic identifier that, when matched against your registered catalog, escalates a candidate duplicate from "needs human review" to "auto-eligible for takedown evidence pack generation." Hard-signal matches dominate the high-confidence detection tier and account for the majority of evidence packs the platform produces.

The matching pipeline runs in three stages:

1. Catalog ingestion — DSP Watch pulls ISRC, UPC, title, artist and runtime for every track you register, building a normalised owner catalog.
2. DSP sweep — across Spotify, Apple Music, Amazon Music, YouTube Music, Deezer and Tidal, we query for tracks whose ISRC matches any code in your catalog but whose artist or release credit does not match yours. Each such match is a candidate duplicate upload.
3. Evidence pack generation — for confirmed candidates, DSP Watch generates a §512(c)(3)-compliant evidence pack with the matched ISRC, the original release UPC, a hash-chained audit trail, and the right adapter selection (Spotify Content Protection, Apple dispute form, YouTube manual claim, distributor forward, or generic DMCA) based on where the duplicate lives.

For the full architecture and adapter list, see the /product page. For the legal mechanics that the evidence packs satisfy, see the DMCA takedown guide.

8. Frequently asked questions