Six weeks of work. A brief, three directions, two revision rounds, a signed-off two second mark that the client loves.
Then it goes on the website, and on a mid-range Android it fires four hundred milliseconds after the logo animation has already finished. It plays at half the volume of the video below it. On the second page visit it plays again, and on the third, until the visitor mutes the tab.
The sound is fine. The implementation destroyed it.
This is the gap that swallows a lot of sonic branding work. You can run a clean brief, present well, and survive the revision rounds with the brief intact, and still lose the whole thing at implementation. The asset gets designed with care and then handed to whoever builds the site, treated as a file to drop in. But a sound logo is not a UI click and it is not background music. It carries the brand, it has to land on an exact frame, and every one of its failure modes reads to a visitor as cheapness rather than as a technical fault.
Here is what actually has to be true before you call it shipped.
A sound logo has constraints that other web audio does not
Most guidance on web audio optimises for one of two things: keeping file weight down, or keeping playback smooth. Both matter here. Neither is the hard part.
The hard part is that a sound logo is synchronous. It has to hit at a specific moment, usually the resolve of a logo animation, and the human ear notices misalignment far earlier than the eye does. Audio and picture drifting apart by more than about a tenth of a second reads as broken, even to people who could not tell you what is wrong.
It is also repetitive by design. The whole point of a sonic asset is that a visitor hears it many times over years. A sound that is charming once and intrusive on the tenth play is a liability you have installed on every page.
And it is brand-bearing. If a UI hover sound stutters, that is a bug. If your client's sonic signature stutters, the visitor's impression is that the company is careless. You are not protecting a feature. You are protecting the thing you spent six weeks building.
Those three properties drive everything below.
The browser decides when audio is allowed, not you
Every modern browser blocks audio playback until the visitor has interacted with the page. A click, a tap, a key press. Not a scroll, not a hover, not a mouse move. This is not a setting you can request your way around, and it is the single most common reason a sound logo silently does nothing in production while working perfectly on the developer's machine, where the page had already been clicked.
So the first design decision is not technical. It is editorial: where in the visit does this sound legitimately belong?
If the answer is "on the hero animation, on page load," you have a problem, because on a cold first visit that playback will be blocked. Options that do work:
Attach it to a deliberate action the visitor already takes. The first click into the site, opening the menu, starting a showreel.
Give it a visible, honest affordance. A small sound toggle in the corner, off by default, that plays the mark when switched on.
Accept that first-visit silence is correct, and let the mark appear on the second interaction onward.
Whatever you choose, unlock the audio context on that first gesture and keep it alive for the rest of the session. Then playback later in the visit is instant and permitted.
Trying to defeat the policy with muted autoplay tricks is not worth it. It degrades unpredictably across browsers and it puts your client's brand in the same category as an ad that shouts at people.
Decode before you need it, not when you need it
The four hundred millisecond delay in the opening example is almost always decode time, not download time.
If you attach a file to an audio element and call play at the moment the animation resolves, the browser has to fetch, decode, and start. On a fast desktop connection this is invisible. On a mid-range phone it is very much not.
For a short brand-critical asset, load and decode it into memory ahead of time, then trigger playback from the decoded buffer. A two second mark is small enough that holding it in memory costs you nothing meaningful, and playback becomes effectively immediate.
The practical sequence:
Fetch the file early, at low priority, so it does not compete with anything above the fold.
Decode it once, on the first user gesture, when the audio context unlocks.
Keep the decoded buffer for the session.
Trigger from the buffer at the exact moment, driven by the same timeline as the animation rather than by a separate timer.
That last point matters more than people expect. If the animation is driven by one clock and the audio by another, they drift, and they drift differently on slow devices. Fire the sound from an animation callback so the two stay locked.
If you are choosing between libraries for this, we compared the two most common options in Tone.js vs Howler.js. For a single brand mark the lighter option is almost always right.
Level is a brand decision, not a mix decision
Your sound logo was mastered in isolation. The web page it lives on is not isolated.
If the mark sits at one level and the showreel below it sits eight decibels louder, visitors will set their system volume for the video and your brand asset becomes inaudible. Reverse the relationship and your brand asset becomes the thing people flinch at.
Set the level for the mark relative to every other sound on the site, not in a vacuum. Then check it on a phone speaker at half volume in a room with background noise, because that is where most of your audience actually is.
Two rules we hold to:
Never ship a sound logo that requires the visitor to turn the volume up. It will not happen.
Never ship one that makes them turn it down. That is a mute, permanently.
Format and weight, briefly
The full decision tree is in our guide to choosing an audio codec, so this is only what changes for a short brand asset.
A two second mark should be a handful of kilobytes, not hundreds. At that size the compression argument mostly disappears and you can afford quality. What you cannot afford is artefacts, because a brand mark heard forty times will expose any low bitrate smearing that a one-off sound effect would hide.
Serve one modern format with one broadly supported fallback. Do not build a six format matrix for a file this small. And check the file for leading silence, because a hundred milliseconds of padding at the head of the file is a hundred milliseconds of delay you cannot fix in code.
Plan for the fortieth listen
This is where most implementations fail, and it is a content decision rather than an engineering one.
Decide the frequency rule before launch:
Once per session is the safe default for a mark tied to site entry.
Once per meaningful action works when the sound is attached to something the visitor chose to do, like opening a project.
Every time is only defensible for very short, very quiet interaction sounds, which a sound logo is not.
Persist that rule for the session so a visitor moving through five pages hears the mark once, not five times. Then go and sit through the fortieth playback yourself before you ship. If you are tired of it, so is everyone else.
Broader touchpoint strategy beyond the site belongs in the rollout plan, and the constraints you discover here should feed back into it.
Give people real control
A visible mute control is not a compromise. It is the thing that lets you use sound confidently at all.
Make it discoverable, make it persist across pages and visits, and make it honest. A toggle that silences the mark but leaves other audio playing is worse than no toggle. Respect system-level reduced motion and reduced data preferences too, since a visitor asking for less is asking for less of this as well.
We covered the wider set of considerations in building an accessible audio experience. The short version: audio that cannot be turned off is audio that gets the whole site muted.
The pass before you call it shipped
Run the mark through this before handing over:
Cold first visit, cache empty, mid-range phone, mobile network. Does it fire, and on time?
Second page in the same session. Does it fire instantly?
Phone speaker at half volume, background noise present. Audible without being sharp?
Against the loudest other sound on the site. Consistent?
Forty consecutive plays. Still tolerable?
Mute toggle. Discoverable, persistent, complete?
Audio blocked entirely by the browser. Does the visual still work alone?
That last one is the safety net. Every animation the sound accompanies must read correctly in silence, because a meaningful share of your visitors will never hear it at all.
The takeaway
A sound logo is finished when it works on a mid-range phone, on a bad connection, at the fortieth play, for someone who never turns their volume up.
Unlock on a real gesture. Decode ahead of time. Lock the trigger to the animation clock. Set level against the rest of the site. Cap the frequency. Ship a mute control that works.
None of this is exotic. It is the difference between an asset that carries six weeks of brand work onto the web intact, and one that arrives there sounding cheap.
The sound was never the risk. The last hundred metres always is.
