How Spotify Offline Downloads Actually Work — The DRM, the Limits, and the 30-Day Clock

When you download a playlist on Spotify, three specific things happen that almost nobody explains. A Premium entitlement check runs on the server and decides whether you are even allowed. Encrypted audio files are copied into Spotify's private app sandbox — not into your Music folder, not into anywhere a file manager can reach. And a local license is issued that starts a 30-day clock which, if it runs out while your device is offline, silently disables your entire downloaded library until you reconnect. The three numbers every Spotify user knows — 5 devices, 10,000 songs, 30 days — are not arbitrary product decisions. They are the visible edges of a DRM and licensing system that Spotify operates under the same kinds of studio constraints Netflix does, just with weaker hardware enforcement because audio is not worth the same rip-protection engineering as 4K HDR video.

This post walks through the architecture behind those three numbers, grounded in Spotify's public documentation of Premium features, reverse-engineered research on earlier versions of the Spotify protocol, and the general patterns used by every modern streaming service running under music-label licensing. Some Spotify-specific implementation details are not publicly documented and I will not guess at them — the patterns described below are the ones common to the category, which is what matters for understanding why downloads work the way they do.

Why Offline Music Is Harder Than It Sounds

If you were Spotify and you wanted to let users "download a playlist for offline listening," the first instinct is: store the MP3 files on the device. Done. This is what MP3 players did in 2005 and it worked fine. It is also the one thing Spotify absolutely cannot do, because:

• Spotify does not own the music. It licenses it from labels (Universal, Sony, Warner, and countless indies) under contracts that specify exactly how the music can be delivered and controlled.
• Those contracts require that Spotify cannot hand users a usable file. The whole license is predicated on Spotify maintaining control over who can play what, when, and for how long.
• A downloaded file the user can copy to another device, share with a friend, or keep forever after canceling their subscription would breach the label deals within minutes.
• Without some mechanism for eventual expiration, "offline download" becomes "permanent free copy" the moment someone unsubscribes.

So the problem becomes: how do you give users the experience of owning a local copy — something that plays instantly, works offline, survives poor network connections — while still maintaining enough control that the labels are happy and the license terms are enforced? The answer is a DRM system that looks structurally very similar to Netflix's offline download system, with some important differences specific to audio.

The Three-Layer Entitlement Model

Every Spotify offline download passes through three entitlement layers, each of which has to grant permission or the download fails.

Layer 1 — Premium subscription check

Offline downloads are a Premium-only feature. Spotify publicly documents this. The check happens at the moment you tap the download toggle on a playlist, album, or liked-songs list. The client sends a request to Spotify's backend that includes your account's current entitlements, and the backend either grants or denies the download operation entirely. Free-tier accounts never see a download button at all — the feature is hidden in the client, but even if you somehow triggered it, the server-side check would fail.

Layer 2 — Catalog rights check per country

Music licensing is regional. A song that is available on Spotify in one country may not be available in another, and even within the "available" set, the terms may differ for offline versus streaming. The Spotify backend, at the moment of download request, checks the catalog rights for your current region — the country tied to your account, not just where your IP is right now. Tracks that do not have offline rights in your region will silently be skipped, which is why sometimes a downloaded playlist has fewer tracks than the playlist you see online.

Layer 3 — Device and song caps

Spotify's publicly documented caps are 5 devices per account and 10,000 songs per device. If you are already at 5 devices, the new one cannot start downloading. If a device is already holding 10,000 downloaded songs, the oldest have to be removed to make room. These caps are enforced server-side at download-request time, with per-device counters maintained in Spotify's backend. This is the direct equivalent of Netflix's "2 devices per offline title" limit, just expressed in terms that make sense for music (where 10,000 tracks is roughly the size of a serious listener's library).

The Actual Download Flow

Once all three entitlement checks pass, the download itself begins. The Spotify client has to fetch the audio content, store it in a way the user cannot access directly, and issue itself a local license that will let it play the content back later, possibly offline. Here is what happens at each step.

Step 1 — Manifest request

The client requests a manifest for each track in the download list. The manifest tells the client which audio files correspond to this track at which quality levels, and critically, includes the encryption metadata needed to decrypt them. Spotify delivers different bitrates depending on device class and user-selected quality settings (on Android the options are publicly documented as Normal, High, Very High, and Automatic). The manifest also declares whether the track is available offline at all for the user's region.

Step 2 — Encrypted audio delivery

The actual audio content is delivered as encrypted files from Spotify's CDN. Historically, Spotify delivered music in Ogg Vorbis format. Modern Spotify supports AAC on several platforms, depending on device. The key point for our discussion is not the codec — it is that the files are encrypted with keys that are not available in the file itself. The audio payload is worthless without the decryption key the license later provides.

The client writes these encrypted files to its app-private sandbox — on Android, under a path like /data/data/com.spotify.music/; on iOS, inside Spotify's sandboxed app container. These locations are isolated from other apps by the operating system and not visible to file managers unless the device is rooted or jailbroken. The files are not named like tracks — they are named with opaque content identifiers that only the Spotify app knows how to map back to songs.

Step 3 — Local license issuance

A license for the downloaded content is issued and stored in the client's local DRM subsystem. On Android, Spotify uses Google's Widevine DRM to handle protected content, which is the same DRM system Netflix uses (covered in detail in the Netflix DRM deep dive). Widevine is the de facto standard for Android and browser-based content protection and Spotify leverages it rather than building its own DRM stack from scratch on that platform.

The license carries an expiration timestamp. Spotify's publicly documented rule is that offline downloads remain valid as long as the device has connected to Spotify's servers at least once every 30 days. What that means architecturally is that the license is issued with a fresh expiration every time the device checks in — the 30-day clock is not counting down from when you first downloaded the song, it is counting down from the last successful check-in. Every time you open the app with a network connection, the clock resets for every downloaded track on that device.

Step 4 — Playback uses the CDM or platform DRM

When you tap play on a downloaded song, the Spotify app loads the encrypted file, hands it along with the license to the platform's DRM subsystem (Widevine Content Decryption Module on Android, a platform-specific mechanism on iOS), and the DRM subsystem decrypts the audio samples into a memory region the app's audio pipeline can read. The decrypted PCM samples are then played through the normal Android or iOS audio subsystem.

Notice what does not happen: the decrypted audio is never written to disk. The decryption happens in memory at playback time, and the cleartext samples exist only transiently while they are feeding the audio output. This is weaker than the video equivalent — hardware-backed video DRM keeps decrypted frames entirely inside a secure GPU path, while audio typically runs through general-purpose memory — but it is still enough to prevent a naive "copy the file and play it somewhere else" attack.

Why Audio DRM Is Weaker Than Video DRM (On Purpose)

If you have read the Netflix DRM deep dive, you know that video uses elaborate mechanisms like Widevine L1, hardware-backed TEE decryption, HDCP on the HDMI output, and GPU-level secure memory paths. Audio DRM is dramatically simpler, and this is a deliberate trade-off based on economics.

• The stakes are lower per file. A Netflix 4K movie represents a large production investment that studios desperately want to protect. A song, while valuable in aggregate, is a much smaller individual asset. The cost of building strong hardware DRM for audio is not justified by the per-file loss from ripping.
• Audio is trivially captured via the analog hole. Any rip-protection at the digital level is defeated by simply recording the device's audio output. This has been the case since cassette decks. Strong DRM cannot prevent this, only make it slightly inconvenient. Labels accept this reality for audio in a way they do not for video.
• Users expect audio to work everywhere. Audio plays through Bluetooth speakers, car audio systems, wireless headphones, AirPods, home theater receivers. Any DRM strict enough to encrypt these output paths would break basic user expectations. Music services have learned that strict DRM kills adoption.
• Licensing is time-bound, not copy-bound. Music labels care much more about when and how long you can listen than about whether a determined attacker could rip a song. A subscription model with 30-day expiry serves the time-bound constraint perfectly without needing hardware enforcement.

This is why Spotify downloads are encrypted, device-bound, and time-limited — enough to enforce the subscription model and prevent casual file sharing — but not hardened in the way Netflix 4K content is. The DRM does its job by making the easy attacks unprofitable, not by making all attacks impossible.

The 30-Day Clock — What Really Happens When It Expires

Spotify publicly documents that downloaded music requires a network check-in at least once every 30 days. What actually happens when the clock runs out? The answer depends on what state the device is in when the clock hits zero.

If the device is online and the clock reaches 30 days since the last check-in, the next time the Spotify app runs it will contact the backend, verify the subscription is still active, and refresh the license expiration for every downloaded track. The user notices nothing. This is the happy path, and for anyone who opens Spotify regularly, the 30-day rule is invisible.

If the device has been offline the entire time — you took a phone to a remote cabin for a month, or you have kept an old tablet in airplane mode with downloaded music — then at some point during playback the client detects that its local license has expired. It refuses to decrypt new tracks, and existing playback stops at the end of the current song. The user sees a message that the downloads need to be refreshed and must connect to Spotify's servers. Once they do, the subscription status is re-verified, licenses are re-issued, and offline playback resumes. The encrypted audio files themselves are never deleted — they sit on the device the whole time, useless without a valid license, then become useful again the moment the device reconnects.

This is the same pattern as Netflix offline downloads, and it is also the same pattern as any enterprise software that says "device must check in to license server every N days." It is a canonical example of self-enforcing authorization with a heartbeat requirement: the license is the authority, the heartbeat keeps it fresh, and absence of heartbeat eventually revokes access without the server needing to reach out.

Why Reinstalling Spotify Resets Your Download State (Mostly)

An interesting quirk: unlike Netflix, where persistent licenses survive an app uninstall because they live in the CDM's secure storage, reinstalling Spotify generally does clear your downloaded music. Why the difference?

The reason is that Spotify's use of DRM is less deeply integrated with platform secure storage than Netflix's. Spotify stores its downloaded files and most of its download state inside its own app data directory, which is wiped when the app is uninstalled on Android. On reinstall, the app has no local knowledge of previous downloads and starts fresh. The server-side device cap still counts your new installation as a device (potentially bumping the limit) until old devices get garbage-collected from the backend.

Netflix, by contrast, leans on Widevine's persistent license store, which is part of the CDM and survives app uninstall on most devices. The architectural difference is partly historical — Netflix was designed around Widevine persistent sessions from the start, while Spotify's download feature predates widespread Widevine adoption and evolved from an earlier Spotify-proprietary system. Both approaches work; they just feel slightly different to users.

The Architectural Patterns Worth Stealing

Building a music service is a niche problem. Building anything that needs to authorize offline access to protected content is not. The patterns Spotify uses for offline downloads show up across every DevOps and distributed systems domain:

• Tiered entitlement checks. Spotify runs three independent checks (subscription, catalog rights, device/song cap) and grants only when all three pass. Any authorization system with multiple concerns should compose checks like this instead of folding everything into one monolithic policy — it makes each concern independently reasoning-about-able.
• Encrypted data at rest, with keys held separately. The content can live anywhere — CDN, local disk, third-party cache — because the key is the actual authorization. This is the same pattern as S3 with KMS-managed keys, and it is the reason you can put sensitive data on cheap storage without compromising security.
• Heartbeat-based license refresh. Instead of asking "is this user still authorized" at every playback, issue a license with a short TTL and refresh it on a heartbeat. This removes a hot-path dependency on the backend and still keeps effective control. Every modern short-lived credential system (AWS STS tokens, JWT refresh flows, Kubernetes service account tokens) uses a variant of this pattern.
• Server-side caps enforced at grant time. Check the limit when a new grant is requested, not every time content is used. Grants are rare; uses are frequent. Enforce expensive checks at the rare path.
• Match DRM strength to economic value. Spotify does not burn engineering effort on hardware-backed audio decryption, because the economics do not justify it. Match your security investment to the actual threat model — over-engineering security for low-value assets is as wasteful as under-engineering it for high-value ones.

The last point is especially worth internalizing. A common DevOps failure mode is to apply the same security controls everywhere, regardless of the value of what is being protected. Spotify and Netflix live in the same general category (consumer streaming DRM) but have dramatically different security architectures because the content has dramatically different values. This is the right instinct — your own systems should think about which data is actually worth defending at maximum strength, and accept lighter controls for the rest.

Frequently Asked Questions

Can I download songs from Spotify without Premium?

No. Offline downloads are a Premium-only feature. Free-tier Spotify does not expose the download option at all, and the server-side entitlement check would reject it even if you somehow triggered it.

What are the Spotify offline download limits?

Publicly documented as 5 devices per account and 10,000 songs per device, for a theoretical maximum of 50,000 downloaded songs across all your devices simultaneously.

Why do my downloads expire after 30 days?

The local license requires a check-in with Spotify's backend at least once every 30 days. If your device is online, the check-in happens transparently and the clock resets. If it stays offline that long, existing downloads become unplayable until you reconnect.

Are Spotify downloads MP3 files I can copy?

No. They are encrypted, device-bound files stored in Spotify's app-private sandbox. Copying them to another device produces useless ciphertext, because the decryption keys live in the original device's DRM subsystem.

Does Spotify use Widevine?

On Android and in web browsers, yes. On iOS and macOS, Spotify uses platform-specific sandbox and keychain mechanisms. The general DRM pattern — encrypted content, device-bound keys, local license with expiration — is the same across platforms.

Why is Spotify's DRM weaker than Netflix's?

Because audio is cheaper per file, trivially captured via the analog output anyway, and expected to work through countless speakers and headphones that cannot support strong DRM. Labels accept a lighter DRM for audio because the alternative would destroy the user experience without meaningfully stopping piracy.

---

Next Steps

1. How Netflix-Scale DRM Actually Works — the video equivalent, with much stronger hardware enforcement and the same general pattern
2. How Netflix Downloads Actually Work — the direct parallel to this post, with the full persistent-license flow
3. How Google Docs Real-Time Collaboration Works — another system with invisible infrastructure beneath a simple UI
4. Free DevOps resources

If you made it this far, you now understand music streaming offline DRM better than almost anyone who has not worked on one. The patterns here are not Spotify-specific — they are the general playbook for any system that needs to authorize protected content offline, and they apply to enterprise software licensing, game distribution, ebook readers, and dozens of other categories you have interacted with without thinking about it.