Encode Hidden Text into a PNG / BMP Carrier Image

Hide a short note in a screenshot

The simplest case: a small ASCII message in an ordinary PNG screenshot. Well under capacity, perfect round-trip.

Carrier:  screenshot.png  (1280 × 720 → 921,600 px → ~345,599 char capacity)
Message:  Meet at the library, 4pm. Bring the key.

Encode → screenshot-stego.png  (visually identical PNG)

Decoder check:
  Input:  screenshot-stego.png
  Output: Meet at the library, 4pm. Bring the key.

Encrypt first, then hide the ciphertext

LSB alone hides a message but does not protect it — anyone who reads the same RGB LSBs recovers plaintext. Encrypt with aes-256-encryptor, paste the base64 ciphertext as the message, and the payload is both concealed and unreadable. Note the ciphertext is longer than the plaintext, so size the carrier accordingly.

Step 1 — aes-256-encryptor (AES-GCM 256 + PBKDF2):
  plaintext: "launch code 7731"
  passphrase: correct-horse-battery-staple
  → ciphertext (base64): U2FsdGVkX1+9z...Aa==  (≈ 88 chars)

Step 2 — steganography-encoder:
  Message to hide: U2FsdGVkX1+9z...Aa==
  Carrier: cover.png
  → cover-stego.png

Finding the LSB channel now yields only base64 ciphertext.

CTF flag inside a wallpaper

A common CTF pattern: drop a flag into a high-resolution carrier where the capacity is enormous relative to the payload. Solvers run an LSB decoder to extract it.

Carrier:  wallpaper-4k.png  (3840 × 2160 → ~3,110,399 char capacity)
Message:  CTF{lsb_h1d3s_1n_pl41n_s1ght}

Encode → wallpaper-4k-stego.png

Solver runs steganography-decoder:
  → CTF{lsb_h1d3s_1n_pl41n_s1ght}
(99.999% of the carrier's LSB budget is unused — undetectable to the eye)

Message too large — pick a bigger carrier

The encoder validates capacity before writing anything. A 256×256 icon holds only ~24,575 characters; a longer note throws and produces no file. Switch to a larger carrier and re-run.

Carrier:  icon.png  (256 × 256 → 24,575 char capacity)
Message:  <a 40,000-character document>

Result:
  Error: Message too large for this carrier image. Use a larger image.
  (no PNG produced)

Fix: re-run with a 1024×1024 carrier (~393,215 char capacity).

Why a JPEG carrier source is risky

You can upload a JPEG — Canvas decodes it to pixels — but the JPEG's own compression artifacts already perturbed the LSBs before you ever touched them. The encode still succeeds (output is PNG), but if anyone re-saves your stego PNG back to JPEG, the message is destroyed. Always keep and share the PNG.

Upload:  photo.jpg  (decodes fine on Canvas)
Message: rendezvous confirmed
Encode → photo-stego.png   ✅ message survives (PNG is lossless)

Danger:
  photo-stego.png  →  re-saved as photo-stego.jpg
  Decoder output:  (no LSB-encoded message detected)
  → JPEG re-compression rewrote every LSB.

If the Message to hide textarea is blank, the processor throws Enter a message to encode. before doing any Canvas work. There is nothing to embed, so no PNG is produced. Type at least one character.

Before writing pixels the encoder checks that (chars + 1) × 8 ≤ pixels × 3. If the payload (plus its NUL terminator) overflows the carrier, it throws Message too large for this carrier image. Use a larger image. and produces no file. Pick a carrier with more pixels — see the capacity table.

Characters are packed with charCodeAt(0) and assumed to fit in 8 bits. Code points above 255 (emoji, CJK, many symbols) overflow a single byte, so the bit stream desynchronises and the decoder returns garbage. Keep the payload in the 0–255 Latin-1 range, or encrypt/base64-encode non-Latin text first so the carried characters are all ASCII.

The stego image is delivered as a lossless PNG so the LSBs survive. The moment it is re-encoded through any lossy step — saving as JPEG, a chat app that re-compresses uploads, a CMS that converts to WebP — every least-significant bit is rewritten and the message is lost. Distribute and store the original PNG only.

Canvas drawImage paints a single still frame. An animated GIF or WebP is flattened to its first frame, and only that frame's RGB LSBs carry the message. The output PNG is a single static image — animation is dropped. Use a still PNG/BMP to avoid surprises.

If the browser cannot decode the uploaded file (corrupt header, unsupported codec, mislabelled extension), loadImage rejects with Failed to load image and no encode runs. Confirm the file opens in an image viewer, and prefer the standard formats in the ACCEPT_MAP list.

A literal NUL (\0, char code 0) inside your text is indistinguishable from the appended end-of-message terminator. The decoder stops at the first 0 byte, so anything after an embedded NUL is silently dropped. Strip NULs from the payload before encoding.

The encoder overwrites the LSBs unconditionally, so encoding always succeeds on a loadable image regardless of prior noise. The risk is only on the source side: a JPEG carrier's LSBs are already dithered by compression. The encode is fine; just keep the output PNG lossless from that point on.

The encode loop steps i += 4 and writes only channels 0,1,2 (R,G,B), never index 3 (alpha). Transparency is preserved exactly and carries no payload. Capacity is therefore based on 3 channels per pixel, not 4 — don't expect a transparent PNG to give you extra room.

The encoder can pack hundreds of thousands of characters into a large carrier, but the Steganography Decoder stops reading at 100,000 characters. If you embed more than that, the encode is intact but a round-trip via the decoder returns only the first 100,000 characters. Split very large payloads across carriers or keep them under that ceiling.