Blip vs Bleep: Choosing the Right Short UI Feedback Sound for Games

The word "bleep" entered English through broadcast censorship. When a television or radio show needed to obscure a word that could not be aired, it replaced the word with a short, flat tone that the audience immediately understood as "something was said here that you cannot hear." The bleep is that tone. It is a deliberate obstruction, and the fact that it is recognizable as an obstruction is the entire point.

The word "blip" has a different origin. It came from radar, where a blip was the brief flash of light that appeared on the screen when a signal was detected. A blip was not an obstruction; it was a notification. It told the operator that something existed in a specific place at a specific moment, and it disappeared as soon as the scan moved on. The blip is that notification.

These two origins explain why the two sounds are different in games, and why the difference matters more than most designers realize. A blip is a notification that something happened. A bleep is a statement that something exists. The two are often used interchangeably, but they produce different responses in the player, and choosing the wrong one makes the feedback feel slightly off in a way that is hard to identify after the fact.

The blip sound design guide covers the parameters for a blip in isolation. This article is about the choice between the two categories, and the specific situations where one works and the other does not.

What actually separates a blip from a bleep?

The two sounds share a frequency range, a waveform family, and a general shape. The differences that distinguish them are concentrated in three parameters: duration, envelope, and pitch stability.

Parameter	Blip	Bleep
Duration	20 to 60 ms	80 to 200 ms
Envelope	Fast attack, fast decay, no sustain	Fast attack, short sustain, slower decay
Pitch stability	Can drift or have upward slide	Stable, single pitch for the whole duration
Waveform	Sine or triangle	Sine, or square with narrow duty
Perceived role	Notification of an event	Statement of a state

The duration difference is the most important and the most misunderstood. A blip is short enough that the ear does not fully resolve its pitch — it registers as a click with a tonal character rather than as a musical note. A bleep is long enough that the pitch is fully resolved, which means the ear hears it as a specific tone at a specific frequency. This is what makes a bleep feel like a statement and a blip feel like a notification.

The envelope difference follows from the duration. A blip has no time for a sustain stage, so it is attack and decay and nothing else. A bleep has room for a short sustain, which is what gives it the flat, insistent quality that the word "bleep" describes. A bleep without a sustain is just a long blip, and it sounds wrong because it does not have the tonal stability that the ear expects from a sound of that duration.

The pitch stability difference is what distinguishes the two in practice. Blips often have a pitch movement — a short upward slide, a small downward drift — because the movement is what carries the "this happened" character. Bleeps are stable, because the stability is what carries the "this is a state" character. A bleep that slides in pitch starts to sound like a notification again, which defeats the purpose.

Why does duration matter more than pitch when choosing between them?

The instinct when distinguishing a blip from a bleep is to reach for pitch. A higher pitch feels like a blip; a lower pitch feels like a bleep. This is not wrong, but it is the secondary axis, and using it as the primary one produces sounds that are the wrong category with the right frequency.

The reason duration dominates is perceptual. The ear resolves pitch in a window of roughly 40 to 60 milliseconds. A sound shorter than that window is heard as a click with an approximate pitch, and the exact frequency is less important than the timing. A sound longer than that window is heard as a tone with a specific pitch, and the frequency becomes the dominant characteristic.

This means a 30-millisecond sound at 600 Hz is a blip, not a bleep, even though 600 Hz is the lower register that bleeps typically occupy. The ear does not have enough time to resolve the low pitch, so the sound reads as a short notification rather than a low tone. To produce a bleep at 600 Hz, the sound needs to be at least 80 milliseconds long — long enough for the ear to hear the specific frequency and register it as a stable tone.

The reverse is also true. A 150-millisecond sound at 1800 Hz is a bleep, not a blip, even though 1800 Hz is a frequency that blips often use. The ear resolves the pitch, and the sound reads as a high-pitched tone rather than as a short notification. A designer who is trying to make a blip at 1800 Hz and gets a bleep instead has probably made the sound too long, and the fix is to shorten it rather than to lower the pitch.

The practical rule that follows from this: choose the duration first, then choose the pitch. A designer who knows the sound needs to be a blip should start with a duration under 60 milliseconds and then pick a pitch within the blip range. A designer who starts with a pitch and then picks a duration will often end up with the wrong category, because the duration is what determines the category.

Which game situations call for a blip, and which call for a bleep?

The categories map cleanly onto two different kinds of game feedback. A blip is for events: things that happen at a specific moment and then are over. A bleep is for states: things that exist for a period and then change.

Situation	Correct sound	Reason
Button press confirmation	Blip	The press is an event, over instantly
Menu navigation	Blip	Each move is a discrete event
Pickup / collectible	Blip	The pickup happened once
Invalid action	Bleep	The state "you cannot do that" persists
Low health warning	Bleep (repeating)	The state "you are in danger" continues
Timer expiring	Bleep	The end of the timer is a state change
Character speaking	Blip (per character)	Each character revealed is an event
Connection lost	Bleep (sustained)	The state "you are disconnected" persists

The key distinction is whether the player needs to be reminded of the sound after it finishes playing. A blip is designed to be forgotten — it fires, the player registers the event, and the sound is gone. A bleep is designed to be remembered — it fires, the player registers the state, and the sound continues (or repeats) to keep the state in the player's awareness.

The invalid-action case is a good example of where the distinction matters. A player taps a button that cannot be tapped in the current game state. The feedback is not "the button was pressed" (that would be a blip) but "this button is currently unavailable" (that is a bleep). A blip makes the invalid action feel like a normal press that did not work, which is confusing. A bleep makes it feel like the game is communicating a rule, which is what the player needs to understand.

The low-health warning is the opposite pattern. The warning is a state that persists for as long as the player's health is below the threshold. A single bleep played once does not communicate the persistence; a repeating bleep at a regular interval does. The notification and alert sound guide covers the design of the repeating bleep pattern, which is a different design problem from the single bleep.

How do you generate a bleep that does not sound like a blip with a longer tail?

The most common mistake when making a bleep is to take a blip and lengthen the decay. The result sounds like a blip that is dragging, not like a bleep. The reason is that the bleep needs a sustain stage that the blip does not have, and simply extending the decay does not create one.

A proper bleep has four stages: a fast attack (under 5 milliseconds), a short sustain (30 to 60 percent of the total duration), and a moderate decay (the remaining 40 to 70 percent). The sustain is what makes the bleep feel stable; without it, the sound is just a fade-out, and fades read as blips.

function playBleep(frequency, duration, volume) {
    const ctx = getAudioContext();
    const now = ctx.currentTime;

    const osc = ctx.createOscillator();
    const gain = ctx.createGain();

    osc.type = 'sine';
    osc.frequency.setValueAtTime(frequency, now);
    // No frequency change — bleeps are stable

    const attackTime = 0.004;
    const sustainEnd = now + duration * 0.5;
    const decayEnd = now + duration;

    gain.gain.setValueAtTime(0, now);
    gain.gain.linearRampToValueAtTime(volume, now + attackTime);
    gain.gain.setValueAtTime(volume, sustainEnd);
    gain.gain.linearRampToValueAtTime(0, decayEnd);

    osc.connect(gain);
    gain.connect(ctx.destination);
    osc.start(now);
    osc.stop(now + duration + 0.01);
}

// Example: 120 ms bleep at 800 Hz
playBleep(800, 0.120, 0.6);

The setValueAtTime(volume, sustainEnd) line is what creates the sustain. Without it, the gain would start ramping down immediately after the attack, and the sound would be a slow fade rather than a bleep. With it, the gain stays at full volume until the sustain ends, and then decays. The flat section in the middle is what the ear reads as "this is a stable tone."

The sustain length is the parameter that distinguishes a bleep from a long blip. A 120-millisecond sound with a 60-millisecond sustain has a distinct flat section that the ear hears as stability. The same 120-millisecond sound with no sustain (a fade from peak to zero) sounds like a blip that is playing too slowly. The Web Audio blip tutorial covers the envelope for blips; the bleep envelope described here is the same structure with the sustain stage added.

The frequency range for bleeps is narrower than for blips. Bleeps occupy 600 to 1200 Hz, which is the range where the stable pitch reads as "electronic tone" rather than as "musical note" or "alarm." A bleep at 1800 Hz sounds like an alarm; a bleep at 400 Hz sounds like a bass note. The 600 to 1200 Hz range is what most game systems use for their bleep feedback.

What happens when a game uses both in the same interface?

Most games need both sounds, and the interaction between them is where the design either works or becomes confusing. The rule that produces a coherent interface is that the blip and the bleep should share a family resemblance but be clearly distinguishable, and the distinction should map to the event-versus-state difference.

The specific design that works for most games:

• Same waveform family. Both sounds use sine or both use triangle, but not a mix. The shared waveform makes the two sounds feel like they belong to the same interface.
• Same frequency region, different pitch. The blip sits at the higher end of the shared range (1200 to 1600 Hz) and the bleep at the lower end (700 to 1000 Hz). The pitch difference reinforces the category difference without changing the waveform.
• The duration difference is large enough to be obvious. A 40-millisecond blip and a 120-millisecond bleep are clearly different sounds even at the same pitch. A 40-millisecond blip and a 60-millisecond bleep are too close and will be confused. The ratio should be at least 2:1, ideally 3:1.
• Different envelopes. The blip has no sustain; the bleep has a clear sustain section. This is the most important distinction, because it is the one the ear uses to categorize the sound.

The interaction between the two sounds is the same as the interaction between any two feedback categories. A game that uses a blip for a button press and a bleep for an invalid action has two clearly distinct feedback channels, and the player learns the difference within the first few minutes. A game that uses the same sound for both has one feedback channel and the player cannot distinguish the two situations.

The game UI sound design guide covers the broader structure of a UI sound set, including the categories that extend beyond blips and bleeps (clicks, confirmations, notifications, errors). The blip and the bleep are the two shortest categories, and their distinction is the one that players learn first, because it is the one that determines whether their action was registered or their situation was communicated.

How do you test whether you have chosen the right one?

The test for a blip versus a bleep is not whether the sound is pleasant. It is whether the sound produces the right response in the player. A blip should produce the response "something happened." A bleep should produce the response "something is happening."

The first test is the duration test. Play the sound in isolation and count how many syllables the ear hears. A blip is heard as a single syllable — "tick" — because it is too short to resolve into anything more. A bleep is heard as a single syllable with a tonal center — "bee" — because it is long enough for the pitch to be resolved. If the sound is heard as "bee" but was intended as a blip, the duration is too long.

The second test is the pitch-resolution test. Play the sound and try to hum the pitch back. If you can hum it accurately, the sound is a bleep (the ear resolved the pitch). If you can only hum an approximate pitch or cannot hum it at all, the sound is a blip (the ear did not resolve it). This test is the most reliable distinction, because it is based on the perceptual mechanism rather than on the parameters.

The third test is the in-game response test. Play the sound in the situation it was designed for, and observe the player's reaction. A player who hears the blip on a button press should register the press and move on. A player who hears the bleep on an invalid action should stop and try a different action. If the player's behavior is wrong for the sound's category — pressing the invalid button repeatedly because the bleep sounded like a confirmation, or ignoring the valid button because the blip sounded like a warning — the category is wrong.

The final test is the swap test. Play the two sounds swapped: the blip for the invalid action and the bleep for the button press. If the swapped version feels noticeably wrong, the original categorization is correct. If the swapped version feels about the same, the two sounds are too similar and one of them needs to be redesigned.

The swap test is the most useful because it forces the designer to articulate what each sound is supposed to communicate. A designer who cannot say why the swapped version is wrong does not have a clear enough mental model of the categories, and the sounds reflect that lack of clarity. A designer who can say "the bleep on the button press feels like the game is telling me the button is broken" has a mental model that the design can be built on.