Adding audio to a Bubble app

Bubble is not a CMS, it is a no-code web application builder. People use it to build whole products, with their own database, dynamic pages and access rules. But a great many Bubble projects also host content that gets read: a blog, a help centre, a knowledge base, long reference pages. As soon as a text takes several minutes to read, the question of audio comes up: offering a spoken version reaches the readers who browse your app on mobile, on the move, or who simply prefer to listen. This article explains where audio fits on Bubble, what works well, and what you should know before you begin.

What Bubble allows, and what it constrains

Bubble is a hosted platform: you do not have server access, but you have two integration levers. The first is the HTML element, which inserts code (markup or a third-party script) directly into a page of your app. The second is the plugin, since Bubble has an ecosystem of extensions that add reusable components. Either is enough to display an audio player, provided you pick the right approach for your technical comfort.

The main constraint is the way Bubble stores content. Your articles do not live in files, but in the app's internal database, and a single dynamic page (often called something like "article") displays any post based on a URL parameter. That is good news: a player inserted once into that dynamic page will appear on all your content, with no one-by-one work. This is the approach to favour as soon as you publish regularly.

The clean route: the player in the dynamic page

If your content is served by a single dynamic page, the most durable option is to insert the player there once. You place an HTML element just under the article title, configure it to match the current article by its public address, and it then appears automatically on every new post. You stop thinking about audio: it keeps up with your app. Because the player is tied to the article by its public URL, the audio version stays attached to the right page even if you edit the text later.

One Bubble-specific point deserves attention here: URLs. By default, a Bubble dynamic page is often addressed by an unreadable technical identifier. If you have enabled clean addresses (a record's "slug"), make sure the public address served to visitors is stable, because it is what matches the page to its audio.

Automation through a feed or the API

The next question is simple: where does the audio get built when you publish? On a classic CMS, a feed is enough. On Bubble, content lives in a proprietary database, and two paths exist. If your app exposes a feed of its articles, our RSS feed detects new posts and prepares their audio version with no manual step. If the content stays locked in the Bubble database, our API and CMS connectors deliver the same result by another route: your app signals a new article, narration triggers, and the player is ready when the visitor arrives.

This automation logic is exactly what we recommend for no-code builders, and the principle is the same as the one described for Webflow: a single entry point, narration that triggers itself, and no repetitive gesture on every article. The difference is the source of the content, not the mechanics. To understand the three possible routes (extension, API, feed) and their real cost, the WordPress page walks through the same decision on a better-known platform, and the reasoning transfers to Bubble.

The quick route: page by page

If you have little content, or want to test before touching the dynamic page, manual insertion is still an option. You add an HTML element to the page and paste in the player block. It carries no risk to the rest of your app, and it lets you see the real rendering before rolling it out. The drawback is familiar: you repeat the gesture for every new piece of content, which quickly becomes tedious if you publish often.

Bubble-specific things to watch

Three details deserve your attention. First, the split between the editor and the published app: Bubble separates design mode from run mode, and some third-party scripts only activate once the app is deployed. Do not conclude too quickly that a player is broken because it sits inert in the editor. Second, responsiveness: Bubble gives you broad layout freedom, and an inserted player must be checked at your design's mobile breakpoints. Third, performance: a Bubble app can already load a lot of scripts, and a lightweight player loaded asynchronously avoids adding weight to a load time that is often already tight.

In short

Bubble handles an audio version very well, provided you pick the method that fits your volume and the way your content is served. For an app that publishes regularly, insert the player once into the dynamic page and connect the automation (a feed if you expose one, the API otherwise): audio follows your publishing without you having to think about it. For a handful of pages, manual insertion does the job and lets you judge the result. Either way, you give your visitors access to your content that no longer depends on their ability or willingness to read on screen.

Read next

• An audio player in the page or in an iframe: what that choice decides
• Image captions and photo credits: what French text to speech does with them
• Footnotes and note markers: what French text to speech does with them