Summary

  • Mixcloud Ltd is readily tied to an active UK company, a long-running audio platform, current corporate filings and product rules that describe a real operating service rather than a name alone.
  • Public technical clues show Cloudflare at the web edge and Zendesk behind the help centre, but they do not establish origin hosting, audio-storage location, regional failover, a service-level commitment or a Mixcloud-owned network.
  • The support and policy surface is useful for ordinary users and rights complaints, yet a business relying on Mixcloud should obtain direct answers on incident communications, response times, security reporting, data transfers and exit handling before treating the brand as operating assurance.

Start with the counterparty, not the logo

A familiar product name can conceal several different questions. Is there a legal company behind it? Is that company the party offering the service? Does the service demonstrably operate? And, if it fails or mishandles a dispute, can a customer identify a responsible route for remedy? Mixcloud clears the first two tests more convincingly than many small cloud services.

The UK corporate register lists MIXCLOUD LTD, company number 06710137, as an active private limited company incorporated on 29 September 2008. Its registered office is Unit 2255, 275 New North Road, London N1 7AA. The register records radio broadcasting and software development as its business activities. Mixcloud's own Terms of Use name Mixcloud Limited, give the same London address and company number, and say that the company provides the website, related services, widgets and API. That agreement between the statutory identity and the customer-facing contract is meaningful: the brand, the service and the legal counterparty can be joined without guesswork.

The register also identifies three active directors, while the company's 2025 accounts say there is no overall controlling party and that control rests with the board. The register's persons-with-significant-control page likewise carries an active statement that the company has no registrable person or relevant legal entity. These disclosures do not reveal every economic influence or shareholder interest, but they give diligence teams a defined governance surface rather than an anonymous web property.

That is what a directory record should establish first: identity continuity. It should not be mistaken for a certificate that the platform will meet a particular availability, security or support standard. Incorporation proves that an accountable legal person exists. It does not prove how an incident will be handled at 02:00 in a customer's market.

The service proof is substantive

Mixcloud's public material describes an operating model with enough specificity to be tested. It is a user-generated audio platform for DJ mixes, radio shows, podcasts, original tracks and live streams. Its upload guidance distinguishes shows from shorter tracks, lists accepted audio formats, applies publishing limits and explains that uploaded material is scanned. The basic tier allows up to ten published shows and ten published tracks; Mixcloud says older material can remain in drafts and that paid Pro access unlocks unlimited publishing and creator tools.

This matters because the product is not merely file hosting. Its control surface includes ingestion, classification by duration, copyright identification, access restrictions, playback, creator profiles, statistics, subscriptions, monetisation and live streaming. Each function creates a different operating dependency. A radio station using Mixcloud for a live broadcast depends on ingest and real-time delivery. A creator with a large archive depends on account state, metadata, drafts and subscription rules. A listener paying for offline access depends on authentication, billing and entitlement enforcement.

The licensing layer is also central, not ornamental. Mixcloud says it works with rights holders to identify, track, monetise or disable audio, and its public rules limit how many tracks from one artist, album or compilation may appear in a show. Its DMCA policy publishes a postal and email route for notices, describes counter-notice handling and states a repeat-infringer policy. That is credible evidence of a service designed around rights administration. It is not, however, a blanket promise that every upload is cleared everywhere. Creator-subscription terms say availability can vary by geography according to licensing rights, while uploaders retain obligations concerning the material they submit.

The practical consequence is that content availability is jointly shaped by technical health, account status, territory and rights decisions. A buyer should not describe every unavailable programme as an outage, and should not describe a functioning player as proof that a particular catalogue is contractually safe in every market.

Public network clues identify dependencies, not the whole architecture

The visible network surface provides a useful but narrow form of service proof. Public DNS observations on 15 July 2026 showed Cloudflare nameservers for mixcloud.com, Cloudflare-addressed web records and Cloudflare response headers on the main site. The help hostname pointed to mixcloud.zendesk.com, and the returned headers identified Zendesk's help-centre service. The main page also referenced separate Mixcloud hostnames for application requests, thumbnails, waveforms and tag delivery.

Those observations support two modest conclusions. First, Mixcloud was serving a structured, multi-component web application rather than a static holding page. Second, parts of its public delivery and support perimeter relied on specialist third parties. Cloudflare can provide edge delivery and protection; Zendesk can provide ticketing and help-centre functions. Neither observation identifies the operators of the origin systems, the location of uploaded audio, the regions used for processing, the shape of backups, or the failover policy.

There was also no evidence in this review of a customer-facing Mixcloud autonomous system or dedicated public IP allocation. That absence should not be read as a defect: many software services deliberately sit behind cloud and edge providers. It does mean that an ASN or edge address should not be used as shorthand for ownership or control. The edge tells a customer where a request first meets a delivery provider, not where Mixcloud's complete operating responsibility begins and ends.

For procurement, the unresolved questions are more valuable than an invented architecture diagram. Which regions hold master audio and account records? Are backups confined to the same jurisdiction or replicated elsewhere? Which functions depend on a single provider? Is live ingest isolated from on-demand playback? What recovery objectives apply to uploads, metadata, creator balances and subscription entitlements? Public DNS cannot answer any of them.

Data locality remains a policy question

Mixcloud's Privacy Policy identifies Mixcloud Limited as data controller and describes collection of registration, listening, upload, device, IP, location, profile and payment-related data. It says some listening and social activity is public by default, that data is used for personalisation, rights-holder reporting and service security, and that some public information may be made available to third-party developers through an API.

The policy is explicit that service providers and developers may be outside the European Economic Area. It says information collected in the EEA may be transferred outside it, including to the United States, and cites safeguards such as standard contractual clauses. It also supplies a privacy email address and describes access, portability and other rights for eligible users.

That is useful transparency at the legal-policy level, but it is not a locality specification. The reviewed public material did not give a region-selection control, a map of storage and processing locations, a named subprocessor register, or a commitment that a customer's content remains in one jurisdiction. Nor does the registered office settle the matter: a London counterparty can lawfully use infrastructure and service providers elsewhere.

Any organisation with sovereignty constraints should therefore translate policy language into a written deployment answer. It should distinguish public profile data from private account data, uploaded audio from derived listening analytics, payment tokens from Mixcloud-held billing details, and live-stream buffers from retained recordings. It should also ask how deletion propagates through backups, service providers and rights-reporting records. “Global community” is an operating description; it is not a residency guarantee.

The filings show capacity, with important limits

The latest filed accounts add scale and continuity signals. For the year ended 31 December 2025, Mixcloud reported an average of 35 employees including directors, compared with 37 in 2024. It reported £3.64 million of cash, £5.15 million of current assets, £8.00 million of liabilities due within one year and net assets of £1.17 million. The balance sheet included £6.48 million of intangible assets, principally capitalised development costs. It also named wholly owned subsidiaries in Spain and the United States, alongside a UK subsidiary.

These figures suggest a real software operation with staff, development investment and an international group footprint. They also require restraint. The statements were filed under the small-companies regime and were unaudited; Companies House itself warns that it does not verify the accuracy of filed information. The company changed its accounting policy for development expenditure and restated the 2024 comparison, so year-to-year readings need that context. A balance sheet is not an uptime report, and employee count does not disclose how many people cover support, security, rights operations or on-call engineering.

The register records one outstanding charge created in 2023 in favour of HSBC Innovation Banking. That is a financing fact, not a verdict on service stability. More useful for an operational buyer is the company's own going-concern statement: the directors said they expected adequate resources to meet obligations falling due for at least 12 months from approval of the accounts. It is a board assessment within unaudited financial statements, not an independent availability assurance.

Support is visible, but service accountability is not fully specified

Mixcloud offers a substantial help centre with product, billing, copyright and safety guidance. Several pages point users to a request form, creator-subscription terms publish [email protected], the privacy policy publishes [email protected], and the DMCA page provides [email protected] plus a postal address. This separation is sensible: a rights complaint, a privacy request and an account problem should not enter the same process without triage.

The limits are equally visible. The support request route reviewed on 15 July led to a Zendesk sign-in page. The reviewed public pages did not state support hours, first-response targets, severity definitions, an escalation ladder or a service-level agreement. A plausible Mixcloud Atlassian status-page address returned an inactive page, and the main site's standard security.txt location returned a not-found page. These observations do not prove that Mixcloud lacks internal incident response, private customer escalation or a security reporting process. They show that those assurances were not discoverable through the public routes tested here.

That distinction matters when a creator's income, a broadcaster's schedule or a venue's live programme depends on the platform. A help article can explain expected product behaviour. It cannot tell a customer when an incident commander will respond, how widespread disruption will be announced, or whether a payment and entitlement problem receives higher priority than a cosmetic fault.

The right conclusion is conditional confidence

Mixcloud has enough evidence to be treated as a genuine operating company. Its legal identity matches its service terms; its product rules describe specific controls; the platform and API routes respond; rights and privacy contacts are published; current filings show staff, assets and a continuing group. Those are stronger signals than a polished homepage or a directory name.

They support confidence in identity and present service activity, not unconditional reliance. Before making Mixcloud part of a critical broadcast, archive or paid creator workflow, a customer should seek a written statement covering availability commitments, incident notification, security contact and disclosure, support hours and escalation, data and backup locations, subprocessors, recovery objectives, content export, and the treatment of subscriptions and creator balances during suspension or exit.

It should test those answers against the exact product being bought, because live streaming, on-demand archives and listener subscriptions do not carry the same failure modes.

The decision rule is simple. Treat public identity as the beginning of diligence, service behaviour as evidence of current operation, and direct contractual commitments as the basis for assurance. Mixcloud passes the first two tests. The third still depends on questions that a serious customer must put to the company itself.