How to Add Background Music to Your Website

Background music is one of the few website features that can improve a visit and ruin one using exactly the same code. Get it right and a portfolio, a restaurant page or a game landing page gains atmosphere the moment it loads. Get it wrong and a visitor scrambles for the mute button, closes the tab, and never comes back.

The difference is almost never the audio file. It is whether the person visiting has any control over what just happened to them.

This guide covers how to add background music to a website properly: what browsers will and will not let you do, how to build the control that makes audio welcome rather than hostile, the accessibility rules that apply the moment sound is involved, and how to decide whether your site should have music at all. If you want to skip ahead and build one, the background music widget templates are the fastest route.

Background music is not the same thing as an audio player

These get treated as one feature and they are two, with different jobs and different rules.

An audio player is a visible thing a person chooses to press. A podcast episode, a music sample, a voice testimonial, a recorded lesson. The visitor sees a play button, understands what it will do, and decides. Consent is built into the interaction.

Background music is ambient. It plays behind the page, usually on load, usually without anyone asking for it. Nobody pressed anything. That single difference is why background music has a whole set of constraints an audio player does not, and why copying an audio player setup into a background role produces something that feels broken.

If what you actually want is the visible, press-to-play kind, build that instead: it is a different template and a much easier problem. This article is about the ambient case.

The practical test is simple. If a visitor would be surprised that sound is happening, you are building background music and everything below applies.

What browsers will actually let you do

Here is the part that surprises people who have not tried this recently: you cannot reliably autoplay audio with sound on the modern web. Not because it is discouraged, because it is blocked.

Every major browser now gates audible autoplay behind some form of user engagement. Chrome uses a media engagement score, based on whether that particular visitor has previously played media on your domain and for how long. Safari blocks audible autoplay by default and requires a gesture. Firefox blocks it and can show the visitor a permission prompt. Mobile browsers are stricter still.

The consequences matter for how you build.

Your audio will be silently blocked for most first-time visitors. Not an error, not a warning. The play call is rejected and nothing happens. If your design assumes music started, it will look broken to the majority of the people who see it.

The same visitor can get different behaviour on different days, because engagement scores change. A page that plays music for you while you are building it may not play it for anyone else, which is the single most common reason people think their widget is faulty when it is working exactly as designed.

Muted autoplay, by contrast, is allowed. Video that starts muted plays fine everywhere. This is why so much of the web has silent looping video and so little has audible looping music. The permission model is not hostile to media, it is hostile to unrequested sound.

So the only design that works consistently is one where audio begins after a deliberate action. That sounds like a limitation and it is actually the fix: the action is also the consent, and consent is what makes background music tolerable.

The pattern that works: sound on, by choice

The reliable approach has three parts, and each solves a specific failure.

Start silent, always. The page loads and there is no sound. Nothing is blocked because nothing was attempted, and nobody is startled. Your layout never depends on audio having started.

Offer an obvious, persistent control. A small speaker icon, fixed in a corner, visible without scrolling. Not hidden in a menu, not revealed on hover, not a thin line of text in the footer. A visitor who wants atmosphere finds it in under a second, and a visitor who does not is never bothered.

Remember the choice. If someone turns music on, keep it on as they move through the site. If they turn it off, keep it off, and do not ask again on the next page. Re-prompting somebody who already declined is the behaviour that makes people leave.

That is the whole pattern. It sounds modest, and it is the difference between a feature people use and a feature people flee.

One convenient detail: the browser gesture requirement means the visitor's click on your speaker icon is what unlocks audio. So the control you built for politeness is also the technical mechanism that makes playback work. One element, two problems solved.

Set up the control and the file once with the background music widget and this behaviour comes configured rather than hand-built.

Accessibility is not optional here

The moment a website makes sound, accessibility guidance stops being advice and becomes a specific, testable requirement.

The relevant rule is unambiguous: if audio plays automatically for more than about three seconds, there must be a mechanism to pause or stop it, or to control its volume independently of the system volume. Telling people to turn down their speakers is not a mechanism. Neither is closing the tab.

Beyond the letter of it, there are people for whom unexpected audio is genuinely harmful rather than merely annoying.

Screen reader users are the clearest case. A screen reader is speech. Background music competes directly with the thing they are using to read your page, and depending on volume and mix it can make a site not merely unpleasant but unusable.

People with auditory processing differences or sensory sensitivities may find unexpected sound disorienting or painful, not just unwelcome.

Anyone in a shared space has a social problem rather than a design one. An open-plan office, a library, a lecture, a train, a room with a sleeping baby. Sound arriving without warning has consequences that have nothing to do with your layout.

People on metered connections pay real money for an audio file that loads on every page view, for something they did not request.

The start-silent pattern above satisfies all of this at once, which is a good sign it is the right pattern rather than a compromise. If your control is visible, your audio is off by default, and the choice persists, you have handled the accessibility requirement and the etiquette problem with the same three decisions.

Keep the volume conservative too. Background music should sit under the content, not compete with it. If a visitor has to turn the music down to concentrate on reading, it is mixed too loud.

Choosing and preparing the audio

The file matters more than people expect, mostly for reasons of weight and looping.

Keep it small. A background track is a supporting detail, not the payload. Something in the low hundreds of kilobytes is reasonable; several megabytes of high-bitrate audio on a page that also has images is not. Compress harder than you think you need to, because background music is heard at low volume, under other sound, often through laptop speakers, and the quality difference is largely inaudible in that context.

Loop cleanly, or do not loop. A track with an obvious seam every ninety seconds draws attention to itself, which is the opposite of ambient. Either use audio written to loop, trim carefully so the end flows into the start, or accept that it plays once and stops. A single clean pass often beats a badly looped bed.

Use a format that works everywhere. MP3 is universally supported and the safe default, and AAC is fine. Anything more exotic needs a fallback, and for a decorative feature the complexity is rarely worth it.

Get the rights. This is the boring one that ends in a real bill. Commercial music on a business website needs a licence, and finding it on a video site is not one. Use a library that licenses for web use, buy the track, or commission it, and keep the licence document somewhere you can find it, because the person who asks for it will not be you.

Finally, consider whether you want music at all. Some of the best ambient audio is not music. A coffee shop page with faint room noise, a nature site with birdsong, a game landing page with a low synth pad. Non-musical beds are often easier to license, easier to loop, and much less likely to clash with whatever the visitor is already listening to.

Where background music earns its place, and where it does not

Being honest about the second list saves more visits than the first one wins.

It tends to work on portfolios and showreels, where atmosphere is part of the work. On restaurant, bar and venue pages, where you are selling a room and its feeling. On game and entertainment landing pages, where audio is part of the product anyway and the visitor half expects it. On event and wedding pages, where the visitor arrived deliberately and emotionally. And on immersive, scroll-driven stories, where sound is part of the composition.

It tends to fail on anything transactional. Checkout, forms, pricing, account settings. A person trying to complete a task does not want a soundtrack, and audio at the moment of payment reads as unserious.

It fails on content people read. Documentation, blogs, news, help centres, anything long. Reading and music compete for the same attention, and the reader loses.

It fails on B2B and professional services, where the connotation is dated in a way that costs credibility, fairly or not.

And it fails on any page a person might open at work, which in practice is most pages, which is the real argument for the control being visible and the default being silence.

If you are unsure, the deciding question is not whether this would be nice, but what happens to the person who did not want it. If the answer is that they mute it in one obvious click and nothing else is lost, go ahead. If the answer is that they leave, do not.

Adding it to your site

The mechanics are the easy part once the decisions above are made.

Pick a template and set your track. Start from a background music widget template, upload or link your audio, and set the initial state to off. Everything in this guide is a setting rather than a rebuild.

Position the control where it can be seen. A fixed corner is conventional for a reason: it is visible on load, it survives scrolling, and it does not move around. Match the icon to your palette so it reads as part of the design rather than a stray browser control.

Decide the scope. One page, or the whole site? Site-wide continuous playback is nicer for atmosphere and needs the choice to persist across navigation. Single-page audio is simpler and often enough.

Embed it. The widget produces a snippet that goes into your page, or into your site builder's HTML or embed element. It works the same way in WordPress, Shopify, Wix, Squarespace, Webflow and hand-written HTML, because it is just a snippet.

Then test like a stranger. This is the step people skip and it is the one that catches everything. Open the page in a private window, in a browser you have never played media in, on a phone as well as a desktop. That is what a real first-time visitor gets. If you test in the tab you have been building in, your own engagement score will show you a version of the page nobody else can see.

Check three things while you are there: the page is silent on load, the control is findable without hunting, and turning it off keeps it off.

Common mistakes, and what to do instead

Autoplaying with sound. It is blocked for most people and startles the rest. Start silent and let the visitor choose.

Hiding the control. If a visitor has to hunt for the mute button, you have built a trap. Put it in a fixed corner, visible on load.

Forgetting the choice. Music that restarts on every page turn undoes the visitor's decision. Persist the state.

Mixing it too loud. Background music should be under the content. If it competes with reading, it is too loud.

Shipping a giant audio file. Several megabytes for a decorative loop is a real cost on mobile. Compress it.

Leaving an audible loop seam. A click or a jump every couple of minutes makes ambient audio conspicuous. Trim it, or let it play once.

Assuming it worked because it worked for you. Your browser knows you. Test in a private window on a device you have not used, or you are testing nothing.

Using music you have not licensed. The cheapest moment to sort this out is before you publish.

Making it work on a site people navigate

Most guides stop at a single page, and most real sites are not a single page. Two extra decisions come up as soon as a visitor clicks through to a second page.

The first is continuity. If music stops and restarts on every page load, the effect is worse than no music: the visitor gets a fresh two seconds of intro over and over, which reads as a bug. On a conventional multi-page site each navigation is a new document, so audio genuinely does restart. There are three honest options. Accept it, and choose a track whose opening is unobtrusive enough that a restart is not jarring. Limit audio to one page, usually the home page or a specific landing page, so the situation never arises. Or use a site whose navigation happens without full page reloads, where playback can survive the transition. Pick deliberately rather than discovering the behaviour after launch.

The second is the remembered state, which has to be stored somewhere the next page can read. Whatever the mechanism, the rule that matters is the one from earlier: a visitor who turned music off should not be asked again. It is worth testing this explicitly, because it is easy to build the toggle correctly and still lose the answer on navigation, and the result is a site that argues with the person using it.

There is also a mobile consideration worth planning for. On a phone, background audio interacts with whatever else is playing. If your visitor is listening to a podcast and your page seizes the audio channel, you have not added atmosphere, you have interrupted them. This is another argument for silence by default: on mobile it is not merely polite, it avoids a genuinely bad outcome that you will never see in your own analytics.

Frequently asked questions

Can I make music autoplay on my website?

Not reliably, and not with sound. Every major browser blocks audible autoplay unless the visitor has already engaged with media on your domain, so for most first-time visitors the attempt is silently rejected. Muted autoplay is permitted, which is why silent looping video is common and audible looping music is not. Build for a visitor who chooses to turn sound on.

Why does my background music play for me but not for anyone else?

Because your browser has an engagement score for your own site and a stranger's does not. You have loaded that page dozens of times while building it, which is exactly the signal that unlocks autoplay. Test in a private window, in a browser you have never played media in, and on a phone. That is the real first-time experience.

Does background music hurt SEO?

Not directly, in the sense that there is no ranking penalty for having audio. It can hurt indirectly in two ways worth caring about. A heavy audio file that loads on every page view slows the page down, and page speed does matter. And if unwanted sound makes people leave immediately, the behavioural signal is not doing you any favours. Keep the file small and the default silent and neither applies.

Is background music bad for accessibility?

Unrequested audio that a visitor cannot stop is an accessibility failure, and the requirement is specific: audio playing automatically for more than a few seconds needs a mechanism to pause, stop, or control its volume independently. Audio that is off by default and has one obvious, persistent control satisfies that, and is also simply better for everyone.

What kind of audio works best in the background?

Something quiet, loopable and unobtrusive, and often not music at all. Room tone, ambient pads, faint birdsong or light instrumental beds sit under content without competing with it. Anything with vocals, a strong beat or a big dynamic range fights whatever the visitor is trying to read.

Do I need a licence for music on my website?

Yes, if it is not yours. A business website is commercial use, and that needs a licence from a library that grants web use, a purchased track, or something commissioned. Sort it out before publishing and keep the document, because the moment somebody asks for it is not the moment you want to start looking.

Where to start

Background music is a small feature with an unusually wide range of outcomes, and almost all of the variance sits in the defaults. Silent on load, one obvious control, remember the answer, keep the volume under the content. Do those four things and the feature is an asset. Skip them and no audio file will save it.

When you are ready, open the background music widget builder, set your track, leave it switched off by default, and publish. If you decide your page wants a visible player people press instead of an ambient bed, that is a different template and the full widget library has it.