Every link produced by Spotify's share button carries a share identifier called si. The track, album or playlist opens identically without it.
https://open.spotify.com/track/4cOdK2wGLETKBW3PvgPWqT?si=8f2a1b9c3d4e5f60
/track/4cOdK2wGLETKBW3PvgPWqT identifies the song. The si value identifies the share that produced this particular link.
Same name, same idea as YouTube
Spotify uses the same parameter name as YouTube, and for the same purpose. Two people sharing the same track produce two different URLs, because the value describes the share rather than the content.
I covered the reasoning behind these in the YouTube si parameter, and everything there applies here. The interesting question is why two unrelated companies landed on the same parameter name for the same job. My guess is that si for share identifier is simply the obvious abbreviation, and both arrived at it independently. It does make searching for an explanation of either one unnecessarily confusing.
What else turns up
utm_source=copy-link appears when you use the copy option rather than the share sheet. An ordinary campaign tag.
nd=1 and _branch_match_id relate to deep linking, the mechanism that decides whether a link opens in the Spotify app or in your browser.
context records what you were listening to when you shared, such as the playlist a track was in.
t on a podcast episode link is a timestamp in seconds. This one is functional. If you shared an episode at a specific moment, t is what carries it, and removing it sends the recipient back to the beginning.
The rule
Delete si, utm_source, nd, _branch_match_id and context.
Keep t on podcast links if the timestamp was the point.
https://open.spotify.com/track/4cOdK2wGLETKBW3PvgPWqT?si=8f2a1b9c3d4e5f60&utm_source=copy-link
https://open.spotify.com/track/4cOdK2wGLETKBW3PvgPWqT
Link types
Tracks use /track/, albums /album/, playlists /playlist/, podcast episodes /episode/, artists /artist/. In every case the identifier is the string in the path and the query string is disposable, with the podcast timestamp exception.
Why bother with a music link
Honestly, the privacy stakes here are lower than almost anything else in this series. Nobody is going to learn much about you from a Spotify share identifier.
I clean them for a different reason, which is that music links get shared in the least formal contexts imaginable and the URLs are already long. A bare track link is short enough to sit on one line in a message. With the share identifier attached it wraps, and the visible part of the link becomes a string of random characters instead of something recognisable.
There is also a small thing about permanence. Music links get saved into notes, playlists documents, wedding planning spreadsheets, and they sit there for years. A clean URL ages better than one with a share token from 2023 on the end of it.
Cleaning them
Paste into the url cleaner tool online and it strips the share tracking while keeping the track identifier.
Related reading
The YouTube si parameter covers the same mechanism on video links.
The URL tracking parameter glossary lists everything.
Frequently asked questions
Does removing si break the Spotify link?
No. The track identifier in the path is all that is needed.
Is Spotify's si the same as YouTube's si?
Different systems, same purpose and same name. Both are share identifiers and both can go.
Will the link still open in the app?
Yes. App opening is handled by the domain and path, not the tracking parameters.
Should I keep the timestamp on a podcast link?
Keep t if you meant to point at a specific moment.