How Browser-Based Morse Audio Decoding Works: From Beeps to Text

Kalana Wanniarachchi — Wed, 19 Aug 2026 12:02:40 +0000

Converting written Morse code into text is relatively straightforward.

If the input is:

... --- ...

a program can simply split the symbols and map them to letters.

But decoding Morse code from an audio recording is a very different problem.

The browser does not receive dots and dashes.

It receives a waveform containing frequencies, noise, silence, timing variations, and sometimes imperfect recordings.

So how can a browser turn that audio into readable text?

Here is a simplified look at the process.

1. Get the Audio Into the Browser

The first step is obtaining an audio signal.

There are two common sources:

An uploaded audio file
Live microphone input

Modern browsers provide APIs that make both possible without requiring desktop software.

Once the audio is available, it can be represented as a stream of samples that can be analyzed over time.

The important point is that at this stage the application still does not know anything about Morse code.

It only has audio.

2. Find the Morse Tone

A Morse recording may contain more than the signal we want.

There might be:

background hiss
voices
electrical hum
room noise
recording artifacts

The decoder therefore needs to identify the frequency region containing the Morse tone.

A bandpass filter can help reduce energy outside the frequency range of interest.

Instead of analyzing every sound equally, the decoder concentrates on the part of the spectrum where the signal is expected.

This makes the next stage much more reliable.

3. Decide When the Tone Is On or Off

Once the useful frequency range has been isolated, the application needs to answer a simple question repeatedly:

Is the Morse tone currently present?

This sounds easy, but audio levels constantly fluctuate.

Using one fixed threshold can cause problems.

A quiet signal might fall below it, while background noise might occasionally rise above it.

A more useful approach is to estimate the noise level dynamically and adjust the detection threshold.

Hysteresis can also help.

Instead of using exactly the same level to switch both ON and OFF, separate thresholds can reduce rapid false switching when the signal is close to the boundary.

The result is a cleaner sequence such as:

ON
OFF
ON
OFF
ON
OFF

Now the problem is no longer primarily about audio.

It has become a timing problem.

4. Measure Tone Duration

In International Morse code, timing determines whether a signal represents a dot or a dash.

A dot is the basic timing unit.

A dash lasts roughly three dot units.

So after detecting a tone, the decoder measures how long that tone remained active.

Conceptually:

short tone  -> dot
long tone   -> dash

For example:

short short short

can become:

...

which represents the letter S.

And:

long long long

becomes:

---

which represents O.

But tone duration is only half of the problem.

5. Silence Contains Information Too

The gaps between signals are just as important as the beeps.

Different silence durations separate different parts of the message.

A short gap occurs between elements of the same character.

A longer gap separates letters.

An even longer gap separates words.

So the decoder also measures every OFF period.

Conceptually:

short silence   -> same character
medium silence  -> next character
long silence    -> next word

Without this step, a stream of perfectly detected dots and dashes could still be impossible to divide into meaningful text.

6. Estimate the Sender's Speed

Real recordings are rarely produced at exactly the same speed.

One sender might transmit slowly while another sends much faster.

That means a decoder should avoid assuming that every dot has one fixed duration such as 100 milliseconds.

A better approach is to examine the timing of the detected signal and estimate the basic timing unit.

From that estimate, the decoder can classify:

dots
dashes
character gaps
word gaps

This also makes it possible to estimate the approximate sending speed in words per minute.

7. Convert the Detected Pattern Into Characters

Once the signal has been converted into dots, dashes, and spacing, the final stage becomes much easier.

The decoder can build patterns such as:

...
---
...

and look them up in an International Morse Code mapping.

That produces:

SOS

The complete pipeline therefore looks something like:

Audio
  ↓
Frequency filtering
  ↓
Tone detection
  ↓
Timing measurement
  ↓
Dot / dash classification
  ↓
Character separation
  ↓
Morse lookup
  ↓
Text

8. Why Real Audio Is Harder Than Generated Audio

Computer-generated Morse code usually has perfect timing and a clean tone.

Real-world recordings do not.

Possible problems include:

background noise
changing volume
weak signals
clipping
echoes
inconsistent keying
multiple frequencies
incorrect spacing

This is why decoding a typed string such as ... --- ... is much easier than decoding the same message from a noisy recording.

Signal preprocessing and adaptive thresholds can make a large difference.

9. Experimenting With It in the Browser

I built a free Audio Morse Code Decoder to experiment with this process directly in the browser.

It can work with uploaded Morse recordings or live microphone input and converts detected signals into Morse code and readable text.

The interesting part for me was that what initially looks like a simple “beeps to letters” problem quickly becomes a combination of:

Web Audio
frequency filtering
threshold detection
timing analysis
pattern recognition

It is a nice example of how browser APIs can be used for more than conventional UI work.

Final Thoughts

Audio Morse decoding is a good reminder that the difficult part of a software problem is often not the final mapping step.

Mapping:

... -> S

is easy.

Determining that a noisy waveform actually contained three correctly spaced short tones is the interesting part.

Once the audio has been reduced to reliable timing events, the Morse translation itself becomes relatively simple.

For developers interested in Web Audio or small signal-processing projects, Morse code is a surprisingly useful system to experiment with because its rules are simple enough to understand while the real-world audio introduces plenty of interesting engineering problems.

How Web Audio API Powers Real-Time Morse Code Audio Decoding in Modern Browsers

Kalana Wanniarachchi — Sat, 01 Aug 2026 17:16:35 +0000

Most traditional online Morse code tools suffer from outdated user interfaces, slow server-side processing, or lack real-time audio playback. When building a modern Morse utility suite, leveraging the browser's native Web Audio API changes the game.

Key Architecture & Features

Client-Side Audio Synthesis: Instead of loading external MP3/WAV sound files for Dit/Dah sound effects, we synthesize custom sine-wave audio oscillators directly in the browser using the Web Audio API. This ensures zero latency and crystal-clear sound at any WPM (Words Per Minute) speed.
Interactive Audio Practice Trainer:
To help users learn Morse code by ear (rather than memorizing visual dots and dashes), we built a sound-recognition quiz module that generates dynamic audio beeps and validates real-time user input.
Custom Secret Emoji Ciphers:
An algorithm that translates standard Morse code into custom emoji patterns, enabling users to send fun encrypted messages.
Web Audio Signal Decoder:
Using frequency analysis and peak detection, the audio decoder processes incoming sound signals to automatically translate Morse audio back into readable text.

Try the Live Tool & Audio Decoder

If you are interested in exploring the live application or testing out the interactive trainer and audio decoder, check out the project here:

👉 Morse Code Creator & Audio Decoder Suite

What are your thoughts on handling client-side audio synthesis in Next.js applications? Let me know in the comments below!

DEV Community: Kalana Wanniarachchi