Someone adds a click sound to every button. Then a hover sound to every card. Then a whoosh to the menu.
Day one, the site feels alive. Day three, the team mutes the tab.
The sounds were not bad. There was no system behind them. Every sound had the same length, the same level and the same priority, so nothing told the ear what mattered.
A UI sound set fixes that. It is a short list of sounds, each with a job, a length ceiling and a level, built and played the same way. This note is how we build one for a website: the inventory, the tiers, the levels, and the code that plays them without lag. If you want the principles first, start with our five best practices for designing web sound effects. This is the production side.
Start with an inventory, not a sound pack
Before opening a DAW, list every interaction on the site that could make a sound. Then cut the list.
Write each one down with two facts: what the visitor did, and how often it happens in a normal visit. A form submission happens once. A hover over a card can happen fifty times.
Then sort them into four groups:
Confirmations: form sent, item added, download started. Rare, and the visitor wants to know it worked.
Errors and warnings: invalid field, failed upload. Rare, and they must be noticed.
State changes: toggle on, tab switched, player opened. A few times per visit.
Navigation and hover: menu items, cards, links. Constant.
Most of the last group should stay silent. A sound that fires on every hover becomes noise within a minute. If one stays in the set at all, it gets the shortest, quietest slot.
On a typical marketing site, our inventories end up between four and eight sounds. That is a set you can design, test and maintain. Twenty sounds is a sound pack, and nobody keeps a sound pack consistent.
Give every sound a tier

The rule we use is simple: the more often a sound plays, the shorter and quieter it is. It is the same logic as cutting a sonic logo down to one second. A sound you hear constantly has to earn its place by taking almost no room.
We work with three tiers:
Tier 1, moments: a completed purchase, a finished onboarding, the sound logo on a landing intro. Rare. Can run up to a second or two and carry the brand motif.
Tier 2, feedback: confirmations, errors, toggles. A few times per visit. A few hundred milliseconds at most.
Tier 3, ticks: hover, focus, small clicks. Frequent. Under 100 milliseconds, often a single transient with no tail.
Those numbers are our working ranges, not an industry standard. For a reference point, Shopify’s Polaris guidelines capped short interface sounds at 250 milliseconds and long ones at one second (archived page, March 2025). Our tier 2 sits inside that first budget. Tier 1 is the only place we go past it.
There is one more reason to keep everything short. WCAG success criterion 1.4.2 says that if audio on a page plays automatically for more than three seconds, visitors need a way to pause or stop it, or to control its volume independently of the system volume (W3C, Understanding SC 1.4.2). UI sounds play after an action, not on load, but keeping every member of the set well under three seconds keeps you far from that line.
Set levels as a family, not one by one

The most common problem in a UI sound set is not the sound design. It is the balance. Each file was normalized on its own, so the hover tick ends up as loud as the success chime.
Level the set as a family:
Pick the tier 1 sound as the reference. It is the loudest member.
Place tier 2 a few decibels under it. Errors can sit level with confirmations, but they should differ in pitch or rhythm, not in volume.
Place tier 3 clearly below tier 2. If you notice the hover sound on purpose, it is too loud.
Play the whole set in sequence on laptop speakers and on cheap earbuds, at a normal listening volume.
Write the relative levels down and render with fixed settings.
We bake those levels into the files and also keep a gain value per tier in code, so the balance can be trimmed without a new render. Our REAPER render settings for web audio cover the export side: regions, file naming and loudness for short files.
Design the sounds to belong together
A set should sound like it came from one instrument family. The rules we follow:
One palette. Choose two or three source sounds, like a soft mallet, a filtered click and a short synth pluck, and build everything from them.
One key. Confirmations rise and errors fall, but both stay in the same key, ideally sharing a note with your sound logo.
Clean starts. Trim the silence at the head of every file. A UI sound with 40 milliseconds of leading silence already feels late.
Short tails. Fade reverb tails early. A tail that overlaps the next click turns into mud.
Mono is fine. Ticks and confirmations do not need stereo width, and a mono file carries half the channels.
For the file format, our guide to choosing an audio codec for your website compares the options for short files.
Play them with the Web Audio API
One audio element per sound works for a demo. For UI feedback it gets awkward fast, especially when the same sound fires twice in a row. The Web Audio API is built for this job, and three facts shape the code:
Decode once.
decodeAudioData()decodes a file fetched as anArrayBufferinto anAudioBuffer, resampled to the context’s sample rate (MDN). Do it at load and keep the buffers.One node per play. An
AudioBufferSourceNodecan only be played once. To play the sound again you create a new node, which MDN describes as very inexpensive, while theAudioBufferis reused (MDN).Unlock on a gesture. In Chrome, an
AudioContextcreated before the visitor interacts with the page starts in the “suspended” state, and you callresume()after a user gesture (Chrome for Developers, autoplay policy).
Here is the small player we start from:
A few details matter here. The tier gains live in one object, so rebalancing the whole set is a one-line change. A gain of 0.5 is about 6 dB down, 0.25 about 12 dB. The mute choice is stored, so a visitor who turns sound off does not get it back on the next page. And play() stays silent until the buffers are ready, so a click during loading never fires a late sound.
If you already use a library, Howler.js handles the same buffering and unlocking for you. We compared it with Tone.js in Tone.js vs Howler.js.
Give visitors the off switch
On most sites, UI sounds should be easy to silence, and often off until the visitor opts in. Put a visible sound toggle in the header or footer, wire it to setMuted(), and remember the choice.
Never make a sound the only signal of a state. Every confirmation and error also needs a visual cue and text, for visitors who cannot hear it or have the tab muted. Our note on creating an accessible audio experience goes further.
Test the set in context
Listening to files in a folder tells you very little. Test the set on the real site:
Run a full visit. Land, browse, fill the form, submit. Count the sounds you heard. If it is more than a handful, demote or remove some.
Spam the controls. Double-click buttons and toggle fast. Sounds should stack cleanly, not distort.
Play music in another tab. Tier 3 should disappear under it. Tier 1 should still read.
Ask someone else. Hand the site to someone who did not build it and ask what each sound meant.
FAQ
How long should a UI sound be?
In our sets, hover and focus ticks stay under 100 milliseconds, feedback sounds run a few hundred milliseconds, and only rare moments go up to a second or two. For comparison, Shopify’s archived Polaris guidelines used 250 milliseconds for short sounds and one second for long ones.
Should a website have hover sounds?
Usually not. Hover fires constantly, so even a well-made sound turns into noise. If you keep one, make it the shortest and quietest sound in the set, and let visitors turn it off.
Why use the Web Audio API instead of the audio element for UI sounds?
You decode each file once and replay it instantly, as often as needed, with its own gain. A new AudioBufferSourceNode is cheap to create for every play, and the decoded buffer is reused.
The takeaway
A UI sound set is a system, not a folder of files. Inventory the interactions, cut most of them, tier the rest by frequency, level them as a family, and play them through one small player with a mute switch.
If you want a UI sound set designed and built into your site, see our services.



