Audio Steganography Hider

An uncompressed WAV file is a long list of numbers, one per sample per channel — 44,100 samples per second per channel for CD-quality audio. Audio steganography hides a payload by making very small, structured changes to those numbers, or to the frequencies they add up to, so the change is small relative to the recording. How audible it is depends on the algorithm, the payload size and the recording: LSB changes can be very small, Echo Hiding can be heard, and Phase Coding and Spread Spectrum leave signal components that a spectrum analyser can show. This tool supports four ways of doing that, and they differ far more in what they survive than in how they sound.

The output is always a WAV file. If you upload an MP3, your browser first decodes it to 16-bit PCM and the tool embeds into that decoded audio — the hidden data is in the resulting WAV, not in an MP3. To hide data directly inside an MP3 file's structure, use the separate MP3 Steganography Embedder.

Use LSB Audio when the WAV will travel as a WAV — email, USB, a download link, a CTF challenge — and you want the most room. It changes only the lowest bits of the first samples it needs, so a short message touches a fraction of a millisecond of audio. It is also relatively straightforward to investigate with statistical analysis, especially at higher embedding rates.

Use Phase Coding or Spread Spectrum when you need to test recovery after a lossy conversion to MP3, AAC or Ogg Vorbis. In our tests, which used the three test carriers (computer-synthesised speech, a music loop and an ambient track) converted with real MP3, AAC and Vorbis encoders, Phase Coding was decoded exactly after every conversion and Spread Spectrum after all but one (speech through AAC 128 kbps) — see the test matrix below (results apply to the tested encoders and carriers, not to every file or conversion workflow). Phase Coding is the simplest but holds only about 76 bytes per minute; Spread Spectrum in the Lossy-safe profile holds up to 314 bytes per minute (the High-capacity profile up to 1,283, but it failed more of the conversions in the matrix) and is available in Forensic mode.

Echo Hiding is included for completeness and experiments, is available in Forensic mode only, and is labelled experimental in the tool. On the three test carriers, the tool could not read its own Echo output back reliably, so the encoder refuses the file rather than hand you something undecodable. It is not the right choice for speech or music.

Capacity depends on the algorithm, the length of the audio, its sample rate and its channel count — not on its file size in megabytes. All figures here are raw embedding capacity in bytes, before overhead, for exactly one minute of 44.1 kHz stereo audio (2,646,000 samples per channel), and they come from the same formulas the capacity meter uses. The largest message or file you can actually hide is smaller: 1 byte for the filename flag, 48 bytes with a password, plus Reed-Solomon parity if you choose a level; the tool's capacity check subtracts those for your chosen options. LSB at 1 bit, writing to both channels: (2,646,000 × 2 channels × 1 bit − 32 bits of length header) ÷ 8 = 661,496 bytes. At 4 bits per sample that is 2,645,996 bytes. Writing to one channel only halves it, and a mono file holds half as much as the same audio in stereo. Counting convention: capacity is counted in sample frames (one frame is one sample for each channel, so one minute is 2,646,000 frames). LSB multiplies by the number of channels it writes to. Phase Coding writes channel 0 only, and Spread Spectrum adds the same noise-like chips to every channel and reads the average of the channels, so neither grows with the channel count. Spread Spectrum at 1024 frames per bit (the Lossy-safe minimum) holds at most 314 bytes: (2,646,000 ÷ 1,024 = 2,583 bits ÷ 8 = 322 bytes) − 8 bytes of header. This is raw capacity after the Spread Spectrum header and before any filename flag (1 byte), encryption (48 bytes) or Reed-Solomon parity, so the largest message you can hide is 313 bytes without a password and 265 with one. If the read-back check fails the encoder doubles the spreading factor (up to 8,192 frames per bit), so a carrier that needs a higher factor holds less. Echo Hiding holds 318 bytes and Phase Coding 76 bytes.

A note on units: 661,496 bytes is 646 KiB. The capacity meter on the tool divides by 1,024 and labels the result "KB", so it shows about 646 KB where this page says 661,496 bytes (about 661 kilobytes in decimal units). Capacity is the space for what the encoder embeds, which includes anything added before embedding: AES-256-GCM adds 48 bytes (a 4-byte length, a 16-byte salt, a 12-byte IV and a 16-byte authentication tag), the filename wrapper adds a few bytes for a file, and Reed-Solomon adds 10, 20 or 30 parity bytes to every block of up to 223 bytes plus a small header. Spread Spectrum also stores an 8-byte header describing its settings, which the 314-byte figure already excludes.

After embedding, the tool decodes its own output with the Audio Extractor's decoding routines — without the Extractor's shifted-start search, so it only accepts a file that reads back exactly as written — and compares the result to what it meant to hide. If they differ, you get a clear error instead of a file that silently cannot be decoded. For Spread Spectrum this check drives the settings: the encoder starts at the minimum spreading factor of the selected profile (1,024 sample frames per bit for Lossy-safe, 256 for High capacity) and, if the read-back fails, doubles it step by step, up to 8,192, until the payload reads back exactly. A higher factor means lower capacity. The factor is written into an 8-byte header together with the length and a checksum; because that header is itself spread at that factor, the Extractor tries each factor from 256 to 8,192 with your seed and accepts the one whose header agrees.

Without a password the payload is embedded as-is and anyone who finds it can read it. With one, it is encrypted first — see "How Strong Is the Encryption?" below for the exact scheme and its limits.

Reed-Solomon error correction is optional. RS-10, RS-20 and RS-30 add 10, 20 or 30 parity bytes per block and can repair up to 5, 10 or 15 corrupted bytes in each block; if a block has more damage than that, decoding almost always stops with an error. Very rarely, damage beyond the limit can look like a different valid block and decode to wrong bytes. In our simulation (20,000 random trials per level, changing one byte more than the level's limit inside one block) the decoder reported failure every time and never returned wrong bytes; we make no claim for other damage patterns, and over-limit damage can in principle produce either a decoding failure or an incorrect result. Order matters: the payload is Reed-Solomon coded first and the result is then encrypted, so on extraction the password check comes first and Reed-Solomon second. With a password, any damage to the extracted bytes makes the AES-GCM check fail before Reed-Solomon can repair it, so Reed-Solomon helps only payloads hidden without a password; and because AES-GCM authenticates the encrypted bytes before Reed-Solomon decoding, it cannot detect an incorrect Reed-Solomon correction made afterwards (a limitation of the current processing order). Without a password it can repair scattered errors in the extracted payload when the embedding method still lets the payload be extracted; it does not make a lossy conversion safe by itself. It cannot rescue LSB data from MP3 compression, which damages nearly every sample rather than a few.

Spread Spectrum uses a numeric seed to generate its pseudo-random pattern, and the decoder must use the same seed. The default is 42, which the Audio Extractor's Auto-Detect tries automatically. A different seed means you must enter it by hand when decoding, in the Extractor's Forensic mode. A seed is a 32-bit number, so it is a convenience and a mild obstacle, not a substitute for a password — use encryption for secrecy.

If you set a password, the payload is encrypted before it is hidden, in your browser, with the Web Crypto API. The cipher is AES-256 in GCM mode. The 256-bit key is derived from your password with PBKDF2 using HMAC-SHA-256 and 100,000 iterations. Every encryption generates a fresh random 16-byte salt and a fresh random 12-byte IV with the browser's cryptographically secure random generator (crypto.getRandomValues), so encrypting the same message twice gives different bytes. The stored layout is a 4-byte length, the salt, the IV, then the ciphertext followed by a 16-byte authentication tag — 48 bytes added in total. The tag means a wrong password, or any change to the ciphertext, makes decryption fail instead of returning garbage.

These are standard, widely used primitives, but this implementation has not had an independent audit, and using them does not make the system unbreakable. Their limits matter. Anyone who finds the hidden data can copy the ciphertext and try passwords against it offline, so your password is the real defence: use a long random passphrase, not a word or a date. The key derivation uses 100,000 PBKDF2-HMAC-SHA-256 iterations. This is below OWASP's commonly cited 600,000-iteration recommendation for password storage. That recommendation is not a direct requirement for this file-encryption format, but the lower count makes a strong, unique password especially important. The iteration count is fixed in the code and is not written into the file, so raising it requires a new, versioned format so that files already made can still be opened.

Encryption hides what the data says, not that it exists, and it does not hide the length: AES-GCM ciphertext is the same length as the plaintext, and the encrypted layout adds a fixed 48 bytes of overhead: its own 4-byte length field, the salt, the IV and the authentication tag, separate from any length or framing the tool puts around it. No padding is added. There is no key file and no way to recover a forgotten password. We have not measured key-derivation time on phones or older devices, so very large batches or slow devices may take noticeably longer per file. The tool is intended for educational and personal use; do not rely on it as the only protection for sensitive information, or against a well-resourced adversary.