Mixcloud feed widget for any website.

Mixcloud was founded in London in 2008 by Nico Perez, Mat Clayton, and Nikhil Shah, and it solved a problem that every other audio platform either ignored or fumbled: how do you let a DJ upload a two-hour mix that contains a hundred commercial tracks and have that mix be legal in perpetuity, with the original artists paid and the DJ free of takedown anxiety. The answer Mixcloud built is the platform-level royalty model. Rather than ask each DJ to clear sync rights for every track in every mix (impossible and absurd), Mixcloud signed direct licensing deals with the major labels (Universal, Sony, Warner) and with every major performing rights organization in the world: MCPS-PRS in the UK, BMI and ASCAP in the US, SOCAN in Canada, SACEM in France, GEMA in Germany, JASRAC in Japan, and dozens more. Every play on Mixcloud generates a per-spin royalty that flows from Mixcloud to the PRO to the original songwriter and rightsholder. The DJ does nothing. The trade-off, and this is important, is that Mixcloud enforces the no-skip rule (you cannot scrub forward to a specific track or replay a section on demand) because that would break the broadcast-style royalty model the deals are built on. Listeners can pause and play, but not seek, and that single concession is what unlocks every other capability the platform is famous for. SoundCloud cannot do this. YouTube cannot do this. Spotify and Apple Music cannot do this for user-uploaded mixes at all. The result is that working DJs, radio show hosts, and mixtape podcasters have built their entire archives on Mixcloud since 2008, and most of that catalog is irreplaceable elsewhere on the open web. Embedding the Mixcloud feed on your own site means inheriting that royalty model automatically. Every cloudcast played through your widget pays its rightsholders the same way a play on mixcloud.com would.

Mixcloud exposes four distinct primitives through its public API, and each maps to a different job. A single cloudcast embed is what you get from the native iframe code on any Mixcloud cloudcast page. It is fine for one-off embeds (a hero mix on a launch landing page, a guest mix on a label page, a single radio episode on a press kit), but it does not grow on its own and you maintain it by hand every time you upload. A show or series feed pulls every cloudcast tagged with a specific show name (a weekly radio residency, a monthly mixtape series, a recurring guest podcast). Mixcloud's show concept is first-class metadata, not a tag, and it is the right primitive for radio archives, residency landing pages, and any episodic content that has a name and a release cadence. A profile feed pulls every public upload from a Mixcloud profile, in chronological order. This is the right primitive for an individual DJ's portfolio site, a producer's mix archive, or any place where the latest upload should always be the first thing visitors see. The fourth primitive, the category feed, is more curatorial: pull every cloudcast tagged with a specific genre, mood, or BPM range. This is how scene-focused sites and aggregator pages build wider discovery surfaces (every UK garage mix this month, every techno set tagged Berlin, every ambient cloudcast under 60 BPM). Poper supports all four primitives from the same widget config, so you can switch source types without re-embedding the snippet on your site. Picking correctly at the start saves you a re-embed cycle later and keeps your sitemap clean for SEO.

Mixcloud's public API has been stable since 2010 and is one of the more developer-friendly audio APIs on the web. Public read access does not require authentication for any cloudcast that is set to public. You make a GET request to api.mixcloud.com against a username, a cloudcast slug, a show name, or a category, and you get back JSON metadata including the title, the user, the tags, the play count, the favorite count, the repost count, the audio length in seconds, the picture URLs at multiple resolutions, the embed URL, the tracklist (when available), and the upload timestamp. Authenticated access via OAuth 2.0 unlocks per-user data (followers, following, listening history) and is required for posting cloudcasts programmatically, but most embedding workloads only need the public read endpoints. Rate limits are generous: roughly 4,000 requests per hour per app for public endpoints, and Poper caches every API response at the global CDN edge so visitor-facing requests never hit Mixcloud directly. The platform has two paid creator tiers that the widget needs to handle correctly. Mixcloud Pro (launched 2017, formerly Mixcloud Premium for creators) gives uploaders unlimited storage, advanced analytics, the ability to set up paid subscriber tiers via Mixcloud Select, and the right to monetize their content directly. Mixcloud Select is the listener-facing subscription system: a DJ can put specific cloudcasts behind a paid wall and listeners pay a monthly subscription directly to that DJ. Mixcloud takes a small platform cut and the artist keeps the majority. Poper renders Select-locked cloudcasts with a clear subscribe CTA that routes into Mixcloud's own checkout flow, and the widget never tries to bypass the paywall (which would break the royalty deal that makes the whole platform work). Mixcloud Live, launched in 2020, added the ability for DJs to broadcast scheduled livestreams with the same royalty coverage as recorded cloudcasts. The widget supports embedding a profile that includes upcoming Mixcloud Live shows, with a countdown to broadcast time and a tune-in CTA when the stream goes live. None of this exists on any other audio platform.

Embedding a cloudcast on a page and ranking that page for searches related to the mix are two completely different things. A bare Mixcloud iframe is invisible to Google's audio index because Google cannot crawl what is inside an iframe. To be eligible for audio rich results, podcast carousel placement, and music carousel inclusion, your page needs Schema.org structured data that describes the audio. For DJ mixes the right schema is MusicPlaylist (since a mix is a curated sequence of tracks), with each individual track represented as a nested MusicRecording when the tracklist is known. For radio shows and music podcasts, PodcastEpisode is the correct schema, nested inside a PodcastSeries. The required fields for MusicPlaylist are name, numTracks, and track (an array of MusicRecording entries with name, byArtist, and duration). For PodcastEpisode the required fields are name, datePublished, partOfSeries (linking to the PodcastSeries), and timeRequired in ISO 8601 format. Most Mixcloud widgets emit none of this. Poper auto-injects a complete MusicPlaylist JSON-LD block for every DJ mix in the feed (populated from the Mixcloud API tracklist when available, with the tracklist crowdsourced from Mixcloud's partner feeds when not), and a complete PodcastEpisode JSON-LD block for every radio show or podcast episode. Validate after embedding by pasting your page URL into Google's Rich Results Test. Indexing for the podcast carousel and music carousel typically happens within a week of Google recrawling the page. Beyond Google, PodcastEpisode schema is consumed by Apple Podcasts, Pocket Casts, and increasingly by AI search engines (Perplexity, Claude search, ChatGPT search) that build podcast answer cards directly from the schema markup. The schema investment also unlocks a long-tail SEO opportunity that most DJ portfolio sites miss entirely: track-name plus DJ-name searches. When a listener hears a track in a Boiler Room set or in a Rinse FM broadcast and tries to identify it, they search the track name plus the DJ name. Your DJ site, with proper MusicPlaylist schema and the tracklist surfaced inline, becomes a third option in those SERPs alongside mixcloud.com and Discogs, and your domain rather than a third party gets the click and the brand association.

The official Mixcloud iframe is one of the heavier audio embeds on the open web. A single embedded cloudcast pulls roughly 380KB of JavaScript, sets several third-party cookies (for play count tracking and the global Mixcloud user session), blocks the main thread during load, and frequently regresses Largest Contentful Paint by 700ms to 1.2 seconds depending on the visitor's connection. Embed five cloudcasts as standard iframes on a DJ portfolio page and you can lose 12 to 18 Lighthouse points before any other code on the page runs. On a community radio archive page that lists every resident's last six shows (often 30 to 50 cloudcasts) the standard iframe approach is unworkable. The fix is the lite-player pattern, the same approach that works for YouTube and Vimeo. Poper renders only the cloudcast cover art (pulled from Mixcloud's own CDN at the right resolution) and a play button overlay (under 8KB per cloudcast) on initial page view. The full Mixcloud iframe loads only when the visitor clicks play. Visitors who scroll past the widget pay nothing in performance cost. Visitors who click play see the full official Mixcloud player with the no-skip control, the comment thread, the tracklist, the favorite button, the repost button, and the recognizable cloud icon. Mobile playback in particular benefits from this pattern. Mixcloud's iframe is large enough that on a slow 3G connection it can take 4 to 6 seconds to become interactive, which means a mobile visitor who taps play sees a long delay before audio starts. With the lite-player pattern Poper preloads the iframe in the background as soon as the user shows intent (hover on desktop, viewport entry on mobile), so the iframe is ready by the time the visitor decides to play. There are three additional optimizations Poper applies on top of lite mode. First, cover art is converted to WebP on the fly through our edge layer, which typically halves the weight versus the default JPEG. Second, the play-button overlay uses a single inline SVG instead of an image request, which saves a round trip per cloudcast. Third, when the visitor clicks play, the iframe loads with autoplay enabled so the audio starts the instant the player is ready, not after a second click. The combined result is that a community radio archive page with 30 embedded shows in lite mode often outperforms a basic single-cloudcast page in standard iframe mode on every Core Web Vitals metric. For radio stations and DJ collectives, this is the difference between a usable archive site and a Lighthouse failure that hurts every other page on the domain.