Choosing sound effects for apps and games: levels, formats and loudness

Before auditioning anything, list the events that need sound and what each one should communicate:

Pitch direction carries meaning that most people read instantly: rising sounds suggest success or progress, falling sounds suggest cancelling, closing or failure. Use that consistently and players learn your sound language without thinking about it.

Sounds from different sources rarely match. Pick a palette and stay inside it: one family of timbres (soft synth, wood, glass, chiptune) and, for anything tonal, one key or scale. The UI sound pack tunes every musical sound to C major pentatonic for this reason; any two of its sounds played together won’t clash.

• Avoid fatigue. A sound heard hundreds of times a session should be short and soft. Save character for rare events.
• Use variations for frequent game sounds. Footsteps, hits and coin pickups benefit from two to four variants played at random, or one sound with a small random pitch change of a semitone or less.
• Match the visual style. Chip-style blips from a retro SFX pack suit pixel art; soft synthesised clicks suit a calm productivity app.

Two measurements matter, and they answer different questions:

• Peak level (dBFS) is the highest sample value. It tells you whether a file will clip. Well-made sound packs peak a little below full scale, for example −1 dBFS.
• Loudness (LUFS or LKFS) estimates how loud something sounds to people over time. Two sounds with the same peak can differ in loudness by 10 dB or more.

For a whole game mix, commonly cited starting points are around −24 LUFS integrated for console and PC titles and around −18 LUFS for mobile and handheld, based on recommendations from the Audio Standards Working Group. Very short UI sounds are too brief for an integrated loudness reading, so balance them by ear against your music and dialogue.

A starting ladder for interface sounds

Set the most important cues first, then place everything else relative to them:

These are starting points, not rules. Test on the devices your users have: phone speakers barely reproduce low frequencies, so a sound that feels warm on headphones can vanish on a phone.

• Sample rate: 44.1 kHz or 48 kHz both work. Many game engines mix at 48 kHz; use one rate across the project to avoid unnecessary conversion.
• Mono or stereo: sounds that a game engine positions in 3D space should be mono, because the engine creates the stereo image. Flat UI sounds can stay stereo, though mono halves the file size.
• Keep the masters. Ship compressed formats, but keep the WAV originals for future edits.

A click sound that plays 150 ms late feels broken. Keep short sounds ready in memory:

• Unity: set short clips to Decompress On Load; stream only long music and ambience.
• Web: decode sounds into Web Audio buffers once, ahead of time, and play from the buffer. Browsers block audio until the user interacts with the page, so create or resume the audio context on the first tap or click.
• Mobile: use the platform’s low-latency sound APIs for UI feedback rather than a general media player.

A sound that is lovely on its own in a file browser can be wrong in the product, and a plain one can be perfect. Judge sounds where they will actually play:

1. Wire candidate sounds into a prototype, even a rough one, and use it the way a real user would.
2. Try two or three options per event and switch between them quickly. Differences that are subtle in isolation become obvious in use.
3. Listen on the worst speaker your users have, usually a phone held at arm’s length, and on headphones.
4. Check in a noisy room. Notification sounds must cut through; taps and hovers shouldn’t.
5. Play the busiest moment of your game or app and listen for sounds that mask each other. Trim lengths or lower levels until each cue is clear.

Pack previews help you shortlist. Most sound packs, including ours, include an audition file and an index of every sound with its category and duration, so you can find candidates fast before trying them in your build.

1. Never rely on sound alone. Every sound should accompany a visible change, and ideally a haptic on mobile.
2. Give users separate controls for interface sounds, effects and music, and remember their choice.
3. Respect the device’s silent or mute switch and system volume.
4. Don’t autoplay audio on websites. If audio plays automatically for more than three seconds, WCAG requires a way to pause it or control its volume independently.
5. Avoid harsh, high-pitched or very loud error sounds; they can be distressing, and users hear them when they are already frustrated.

For a ready-made set, browse Audio & Sound; interface sounds pair well with animated loaders and status icons. Sound effects are licensed for use inside your own apps and games; they can’t be redistributed as a sound pack.