1. Home
  2. Features
  3. Steganography

Steganography

Your photo can carry more than a memory.

Steganography hides the existence of a message, not only its contents. StegoPixel can place text, images or whole archives inside a photo — in its pixels or its metadata — and read them back later. Nothing leaves your machine.

Two carriers: pixel LSB and metadata channels Optional AES-256-CBC encryption and Reed–Solomon error correction Analyses carriers that arrive from elsewhere

Hide the message — and the fact there is one

Encryption protects a message whose existence is plain to anyone looking. Steganography hides the existence itself — the payload travels inside an image that still opens as an image — and StegoPixel is honest about where each approach breaks.

  • Text, photographs, documents or whole archives all encode the same way.
  • You choose the bit depth and which of the red, green and blue channels the payload occupies.
  • A 16-byte header travels with every payload, recording the header magic, its flags and the payload length.

Two carriers that fail in opposite ways

A payload can live in the pixels or in the metadata. Each choice survives one kind of journey and is destroyed by another, which is why the decision matters more than the encoding settings.

STEG

Pixel-level embedding

Payload bits go into the least-significant bits of the colour channels you choose, and the result is always written as PNG. Capacity grows with the image, the channels and the bit depth — and so does the chance that the embedding becomes visible.

STGM

Metadata channel

The payload rides inside the file's metadata instead of its pixels, with a far larger ceiling: up to 44,984 bytes in JPEG, PNG, TIFF and WebP. It survives pixel-level recompression, but it vanishes the moment somebody cleans the file's metadata.

Carrier trade-offs at a glance
CarrierCapacitySurvivesDestroyed by
Pixel LSB (STEG)Scales with resolution, channels and bit depthMetadata strippingLossy re-encoding
Metadata channel (STGM)Up to 44,984 bytes in JPEG, PNG, TIFF and WebPPixel-level recompressionA metadata cleanup
Pixel payloads do not survive lossy re-encoding

Anything that rewrites the pixels destroys LSB data: re-saving a JPEG, resizing, or uploading to a platform that recompresses. Keep pixel carriers in PNG, TIFF or BMP when the file might be edited or re-shared, and treat a corrupted decode as a re-encoding problem first.

A passphrase, if you want one

Encryption is optional, and it is built from standard, widely reviewed primitives rather than anything bespoke. Turn it on, and the payload is locked before it ever touches the carrier.

  • AES-256-CBC encrypts the payload, with the key derived from your passphrase.
  • Key derivation is PBKDF2-HMAC-SHA256 at 100,000 iterations.
  • Every encrypted payload gets its own 6-byte salt and 16-byte IV, so encoding the same file twice does not produce identical output.
  • A payload is GZip-compressed before it is encrypted, and the compression is kept only when it actually shrinks the payload.
  • A wrong passphrase is reported as a wrong passphrase, not as a corrupted payload.
A lock is not a hiding place

Steganography hides that a payload exists; encryption protects its contents if the carrier is found anyway. Use both — and remember that a high iteration count raises the cost of guessing but cannot rescue a weak passphrase.

Bits get damaged. Reed–Solomon repairs them.

Error correction is a second checkbox. Wrap the payload in a Reed–Solomon code and a carrier that picked up bit-level damage can still give you back what you hid.

  • RS(255,223) over GF(256) corrects up to 16 corrupted bytes in every 255-byte codeword.
  • The code costs roughly 14% of the capacity you would otherwise have.
  • It guards the header as well as the payload, and after a decode the app reports how many bytes it had to repair.
  • It repairs bit-level damage; it cannot resurrect what a lossy re-encode destroyed.
Repaired, and counted

When error correction rescues a payload, the decode says so and tells you how much it had to fix. Read that number before you rely on a heavily damaged carrier.

Capacity, honestly

There is no single capacity number for images — only a number for one file at one set of settings. StegoPixel calculates that number for the file in front of you and shows it before you commit.

The two ceilings
ChannelCapacity
Pixel LSB(width × height × channels × bit depth) ÷ 8 − 16 bytes, where the 16 bytes are the payload header
Metadata channelUp to 44,984 bytes in JPEG, PNG, TIFF and WebP — a typical maximum rather than a guaranteed ceiling
  • More resolution, more channels and deeper bit depth raise the pixel ceiling — and the risk of visible distortion.
  • A live meter reads your payload against the real capacity of the current settings.
  • Over the limit, the app suggests a fix: shorten the payload, raise the bit depth, enable another channel, or switch carrier format.
  • A payload that does not fit is refused — never silently dropped or truncated.
No silent truncation

The number to trust is the one on screen, because it comes from the file itself rather than a rule of thumb. If the payload does not fit, the encode does not start.

When the carrier is not yours

Half of this module faces the other direction: opening an image you were sent and asking what it carries.

  • Detection sniffs the STEG header across all four bit depths and reports the payload's estimated size, type and whether it is encrypted.
  • Decoding walks the same bit depths, handles plain and error-corrected layouts, and reports any bytes it repaired.
  • The metadata channel can be tested the same way: detected without extraction, decoded when you hold the key.
  • Encode & Verify closes the loop — decode what you just wrote and compare it with the original payload, byte for byte.
A silence is not an all-clear

Header detection looks for StegoPixel's own STEG and STGM markers, and payloads written by other tools do not carry them. When the signature is silent, the bit-plane, entropy, noise and modified-pixel views are how you look for disturbed ground.

Look under the surface

A photograph carrying a payload is still a photograph. Four views show you the parts of it that changed — and they work whether the payload is yours or somebody else's.

Bit planes

Eight planes per colour channel, with the least-significant one laid bare. Payload bits live exactly there, and they do not look like photographic detail.

Entropy map

A local Shannon entropy map over 7×7 windows, normalised from 0 to 1. Embedded data pushes the local pattern towards randomness, and the map lights up where it does.

Noise map

A 3×3 neighbour-difference map showing where the fine grain of the image stops behaving like the rest of the frame.

Modified pixels

A heatmap against the original image, or an LSB anomaly scan when the original is not to hand.

  • Auto-enhance, invert and threshold controls pull faint structure into view.
  • Any view exports as a PNG overlay to keep beside the carrier.
  • Recent encode and decode operations are logged as a payload history — 25 entries by default, with a setting to switch it off.
  • An entry can keep a short snippet of decoded text, if you choose.
  • Overwriting a carrier asks for confirmation, with a specific warning when the output format does not match the carrier's extension.

Frequently asked questions

Where should I hide data — in the pixels or in the metadata?

They fail in opposite ways. Pixel embedding survives metadata stripping but is destroyed by any lossy re-encoding; a metadata channel holds more and survives pixel recompression, but vanishes if somebody cleans the file's metadata. Choose the carrier that survives the journey your file will actually take.

How much can one image carry?

Pixel capacity scales with resolution, the number of channels and the bit depth you choose — a deeper embedding carries more and shows more. The metadata channel targets 44,984 bytes in JPEG, PNG, TIFF and WebP, a typical maximum rather than a guaranteed ceiling. The number to trust is the one the app shows before you encode.

What happens to a payload if the image is re-saved?

Pixel payloads do not survive lossy re-encoding — anything that rewrites the pixels destroys LSB data. Reed–Solomon error correction can repair limited bit-level damage, but it cannot reconstruct what a JPEG re-save threw away. Keep pixel carriers in lossless formats such as PNG, TIFF or BMP.

Can it read a payload somebody else hid?

It can report whether a STEG or STGM payload is present — with its estimated size, type and whether it is encrypted — and decode it when you have the passphrase. For carriers from other tools, the analysis views show where the pixels look disturbed, without claiming to read a format the app does not know.