FAQ

No.

Everything happens in your browser, on your device. Images, passwords and messages are processed locally using the Web Crypto and Canvas APIs. Nothing is sent to a backend or stored on a server.

PNG is a lossless format, which means every pixel value is preserved exactly. This is crucial for LSB steganography, where the message is stored in the least significant bits of pixel colours.

Formats like JPEG are lossy and recompress the image, which completely destroys those tiny bit-level changes. inplain.site embeds into PNG and the output is always a PNG, but you can upload JPEG, non-animated GIF, or WebP images which are flattened and converted to PNG before embedding.

The hidden message will almost certainly be destroyed.

JPEG compression throws away detail and rewrites pixel values, including the least significant bits where your message lives. The image will still look normal, but the data you hid inside it will be gone.

To a casual viewer, the image should look completely normal.

However, steganography is not magic invisibility. Experts with dedicated steganalysis tools can sometimes detect patterns indicating that pixels were modified, especially if they are actively looking for stego images.

inplain.site focuses on content confidentiality (through encryption) and practical stealth, not perfect undetectability against forensic-level analysis.

inplain.site uses AES-GCM with a 256-bit key for encryption and integrity protection.

Your password is transformed into this key using PBKDF2 with HMAC-SHA-256, a random salt, and a large iteration count. This makes brute-force guessing significantly more expensive.

AES-GCM ensures that if data is modified or the wrong password is used, decryption fails safely instead of silently returning corrupted text.

If you forget your password, the message is permanently unrecoverable.

The encryption is designed so that without the correct key, the ciphertext looks like random noise. There is no password reset, no backdoor, and the developers cannot help you recover it.

For important messages, consider storing your password in a password manager or in another secure encrypted vault.

Processing time depends on both the image size and themessage size.

• Large images mean more pixels to read and write.
• Large messages mean more data to encrypt/decrypt and more bits to embed into the image.
• Key derivation (PBKDF2) also adds a deliberate delay to slow down attackers.

Very large PNGs or very long messages can take several seconds. Using a smaller image or shorter message will speed things up.

Browsers have limits on canvas size, GPU memory, and RAM for image buffers. Very large images can push those limits, especially when multiple copies (original, working, encoded) exist at once.

To reduce the chance of crashes, inplain.site may downscale large images internally before embedding the payload. However, some devices or browsers may still struggle with extreme resolutions.

If you encounter crashes, try using a lower resolution PNG.

Yes. Any operation that changes pixel values will typically destroy the hidden data.

• Resizing or scaling
• Cropping
• Rotating (if re-saved)
• Filters or heavy adjustments (brightness, contrast, etc.)

Only the original, unmodified encoded PNG is reliable for decoding. If you need to transform the image, do it before encoding.

Yes. You can attach a single file of any type (capacity permitting), which is encrypted and hidden alongside your message or on its own.

In most cases, no – not safely.

Many platforms automatically compress, resize or otherwise modify images (e.g. Instagram, Facebook, Twitter/X, WhatsApp, Messenger, Discord previews). Those transformations usually destroy the embedded data.

If you must send an encoded image:

• Send the PNG as a file attachment, not as an inline image.
• Consider placing it inside a ZIP file.
• Use services that preserve files, such as Signal attachments.

Capacity depends on the image resolution and how many bits per colour channel are used internally.

The app calculates how many bytes the image can hold and compares that against the size of your encrypted message (plus some metadata). If the message is too large, encoding will be blocked and you will be asked to shorten it or use a larger image.

The UI shows how much capacity you are using and whether your message fits.

By design, inplain.site keeps data in memory only for as long as you have the page open. When you refresh or close the tab, your images and messages are gone.

For extra privacy, you can use Incognito/Private Mode or theTor Browser to avoid leaving browser history and reduce cached traces on your device.

Best practice is to share the original encoded PNG file directly.

• Send it as a file attachment, not as an inline image.
• Avoid services that recompress or resize images automatically.
• Tell the recipient to download the file and decode it locally.
• Share the password separately (not in the same message or channel).

To decode a message:

1. Obtain the original encoded PNG file.
2. Upload it to inplain.site.
3. Enter the password provided by the sender.
4. Click DECODE.

The app automatically detects the LSB depth (bits per channel) used when the image was created, so you do not need to choose it manually.

If the password is correct and the image contains valid data, your plaintext message will appear. If the password is wrong or the data has been tampered with, the app will intentionally fill the message box with a large amount of obviousrandom junk instead of a clean message, to make it clear that decoding did not succeed.

Yes. Under the hood, inplain.site uses AES-GCM, which includes an authentication tag. If any part of the encrypted payload is modified, or if the wrong password is used, AES-GCM detects this and refuses to produce valid plaintext.

Instead of showing a subtle error, the app deliberately responds by filling the message area with a large block of random hash-like characters. This makes it visually obvious that something went wrong – either the password is incorrect, the image was corrupted, or the payload was tampered with.

You should never trust a decode that results in random garbage text.

It depends on your risk level and privacy needs:

• Incognito / Private Mode: Reduces local traces by avoiding saved history and some cached data. Good for casual extra privacy.
• VPN: Hides your IP address from your ISP or local network and encrypts traffic between you and the VPN provider. Good if you don't want your network to know you visited the site.
• Tor Browser: Routes traffic through multiple relays for stronger anonymity. Best for high-risk situations, but slower.

inplain.site already uses HTTPS, but these tools can add additional privacy layers, especially on untrusted networks.

No.

The design is zero-knowledge: the developers never see your password, your images, or your encrypted data. Everything is handled locally in your browser.

Without your password and the intact encoded image, the underlying AES-GCM encryption makes recovery infeasible.

Common reasons include:

• Wrong or mistyped password.
• The image was converted to JPEG or recompressed by a platform.
• The file was resized, cropped, or edited after encoding.
• The sender accidentally changed or re-saved the image.

inplain.site automatically detects the LSB depth, so you don't need to choose that manually. If decoding fails, you will typically see a large block of random junk instead of a clean message.

Ask the sender to:

• Re-send the original encoded PNG (as a file, not a preview).
• Confirm the password exactly (case-sensitive).
• Avoid any conversion, filters, or resizing before sending.

inplain.site offers strong encryption, local-only processing, and reasonably subtle embedding. It is suitable for many privacy-sensitive use cases.

However, it is not designed to defeat state-level adversaries or advanced forensic steganalysis. Steganography can be detected with specialised tools, and weak passwords are always a risk.

Treat it as one component in a broader privacy strategy, not your only line of defence for life-or-death scenarios.

Almost always no. Any edit that changes pixel values will typically destroy the hidden data.

If you've edited, filtered, or re-saved the PNG after encoding, the safest assumption is that the embedded message is no longer recoverable.

To keep a message safe, only distribute the original encoded PNG and avoid altering it.

inplain.site supports modern desktop and mobile browsers with good support for the necessary web APIs.

• Supported: recent versions of Chrome, Edge, Firefox, and Safari on desktop.
• Supported: Chrome/Chromium on Android and Safari on iOS.
• Large images and heavy canvas/crypto operations may still be slow or fail on lower-end mobile devices.

For best results, use a modern browser on a reasonably capable device.